Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Tim Bray Says RELAX

ScuttleMonkey posted more than 7 years ago | from the holy-war-schema-2.7 dept.

180

twofish writes to tell us that Sun's Tim Bray (co-editor of XML and the XML namespace specifications) has posted a blog entry suggesting RELAX NG be used instead of the W3C XML Schema. From the blog: "W3C XML Schemas (XSD) suck. They are hard to read, hard to write, hard to understand, have interoperability problems, and are unable to describe lots of things you want to do all the time in XML. Schemas based on Relax NG, also known as ISO Standard 19757, are easy to write, easy to read, are backed by a rigorous formalism for interoperability, and can describe immensely more different XML constructs."

Sorry! There are no comments related to the filter you selected.

Don't do it. (4, Funny)

Anonymous Coward | more than 7 years ago | (#17108948)

When you want to come.

Re:Don't do it. (0, Insightful)

Anonymous Coward | more than 7 years ago | (#17109044)

mod parent up you uncultured heathens

Re:Don't do it. (2, Funny)

Loconut1389 (455297) | more than 7 years ago | (#17109086)

I tried to tag the article with frankiegoestohollywood,zoolander,killthemalaysianp rimeminister but it didn't all fit ;)

Re:Don't do it. (1)

Keith Russell (4440) | more than 7 years ago | (#17109208)

Did you try "bluesteel, letigre, ferrari"?

Re:Don't do it. (1)

Sporkinum (655143) | more than 7 years ago | (#17109340)

Frankie goes to Sunnyvale....

Couldn't agree more (5, Insightful)

antonyb (913324) | more than 7 years ago | (#17108994)

My experience with XML Schema is exactly that; hard to write in the first place, hard to maintain, and regular interop problems between different implementations that make the theory of web services a practical nightmare (idrefs are the first example that spring to mind).


On the other hand, RELAX NG "just works".

(all IME of course...:)

ant.

Re:Couldn't agree more (2, Funny)

camperdave (969942) | more than 7 years ago | (#17109330)

RELAXiNG works for me too.

Maximizing Composability and Relax NG Trivia (4, Informative)

SimHacker (180785) | more than 7 years ago | (#17109478)

Tim Bray is right, and he couldn't have put it better: W3C XML Schemas (XSD) suck. The reason Relax NG is so much cleaner and more powerful than committee-designed XML Schemas, is that it's based on a sound mathematical foundation (tree regular expressions, or "hedge automata theory"). While XML-Schemas suffer from ad-hoc design, committee-burn, lack of focus, and half-baked attempts to solve too many unrelated problems.

Here's some interesting stuff from my blog [donhopkins.com] about the design and development of Relax NG [oasis-open.org] .

-Don

James Clark [oasis-open.org] wrote about maximizing composability:

First, a little digression. In general, I have made it a design principle in TREX to maximize "composability". It's a little bit hard to describe. The idea is that a language provides a number of different kinds of atomic thing, and a number different ways to compose new things out of other things. Maximizing composability means minimizing restrictions on which ways to compose things can be applied to which kinds of thing. Maximizing composability tends to improve the ratio between functionality on the one hand and simplicity/ease of use/ease of learning on the other.

Clark [oasis-open.org] describes the derivative algorithm's lazy approach to automaton construction:

I don't agree that <interleave> makes automation-based implementations impossible; it just means you have to construct automatons lazily. (In fact, you can view the "derivative"-based approach in JTREX as lazily constructing a kind of automaton where states are represented by a canonical representative of the patterns that match the remaining input.)

The Relax NG derivative algorithm [thaiopensource.com] is implemented in a few hundred elegent declarative functional lines of Haskel [thaiopensource.com] , and also in tens of thousands of lines and hundreds of classes of highly abstract complex Java code [thaiopensource.com] .

Clark's Java implementation of Relax NG is called "jing [thaiopensource.com] ", which is a Thai word meaning truthful, real, serious, no-nonsense, and ending with "ng".

Comparing the Java and Haskell implementations of Relax NG illustrates what a wicked cool and powerful language Haskell [haskell.org] really is. The Java code must explicitly model and simulate many Haskel features like first order functions [wikipedia.org] , memoization [wikipedia.org] , pattern matching [wikipedia.org] , partial evaluation [wikipedia.org] , lazy evaluation [wikipedia.org] , declarative programming [wikipedia.org] , and functional programming [wikipedia.org] . That requires many abstract interfaces, [wikipedia.org] , concrete classes [wikipedia.org] and brittle [wikipedia.org] lines of code [wikipedia.org] .

While the Java code is quite brittle and verbose, the Haskell code is extremely flexible and concise. Haskell is an excellent design language, a vehicle for exploring complex problem spaces, designing and testing ingenious solutions, performing practical experiments, weighing trade-offs, and writing succinct, elegant, mathematically rigorous specifications that actually work. Haskell code is useful as a blueprint for implementations in less luxurious languages like Java.

Murata Makoto [oasis-open.org] writes about the differences of implementations of TREX and Relax:

Somebody asked differences between RELAX Core V1 implementations and TREX implementations.

RELAX Core V1 has three implementations of verifiers. One (VBRELAX) is similar to PyTREX; it backtracks. The other two implementations (RELAX Verifier for C++ and RELAX Verifier for Java) are based on non-deterministic bottom-up tree automata; for each element, multiple states (or non-terminals or labels) are assigned.

In my understanding, JamesC's implementation of TREX also uses non-deterministic bottom-up tree automata. However, James constructs tree automata lazily. Consequently, his implementation is extremely fast when your schema is large but your instance is small.

On the other hand, some constructs of TREX make it hard to actually create tree automata in advance. I am concerned, since creation of tree automata is required for type inference (note: XML Query people plan to incorporate type inference into their query language). I am hoping that introduction of reasonable restrictions will make it possible to construct tree automata in advance.

Cheers,
Makoto

Relax NG is the result of unifying TREX and Relax [oasis-open.org] :

JJC reported that he had met with Murata-san (the designer of RELAX) to discuss unification of TREX and RELAX, and that their conclusion was that they felt it was probably possible to arrive at a design that was satifactory to both. There was a general feeling that unification was politically desirable. It was unanimously decided to change the charter of the TC to make the objective be the development of a unified language.

Relax NG is based on "Hedge Automata Theory" -- so what are hedges and why are they called that?

Murata Makoto [oasis-open.org] wrote: I would like to talk about terminology. I have used "hedges" to refer to zero or more trees possiblly prepended, interespersed, and followed by characters. Your <a,c> is more than my hedges; it is a hedge together with a collection of attributes. You wrote "tree", but it is very misleading. We need a better term. How about "attributed hedge"?

James Clark [oasis-open.org] wrote: Attributed hedge is a bit of a mouthful. How about simply forest?

Murata Makoto [oasis-open.org] wrote: Derick Wood strongly believes that a forest is a set of trees rathert than a sequence of trees. In fact, many articles have used forests to mean sets of trees. How about simply hedge or orchard?

James Clark wrote: I beg to differ. I think the term forest is equally appropriate for ordered and unordered collections of trees, which is exactly what is needed for TREX since the thing we are naming is a pair of an unordered collection and an unordered collection [(sic) -- I think he means "ordered collection" -Don]. Forest have also been used for ordered collections of trees. For example, http://www.w3.org/TR/query-algebra/ [w3.org] uses "forest" for an ordered collection of trees, and "unordered forest" for an unordered collection of trees. I dislike "hedge" because I don't think it is closely enough related to "tree"; "orchard" is cute, but I think probably too cute.

Murata Makoto [oasis-open.org] wrote: Before TATA, Gecsec and Steinby was the only book on tree automata. They used forests to mean sets of trees. Prof. Wood is very knoledgeable about formal language theory, and he strongly believes forests are sets. I think that the XML Query WG made a mistake. I e-mailed the editors. "Hedge" was coined by Bruno Coucelle. [Cou89] Bruno Courcelle. On recognizable sets and tree automata. In Maurice Nivat and Hassan Ait-Kaci, editors, Resolution of Equations in Algebraic Structures. Academic Press, 1989. As you know, I used to use forests. However, I followed Prof. Wood's advice and switched to hedges.

Here's some stuff about easy datatype assignment for TREX [oasis-open.org] .

Here's a simple and interesting design for parameterized patterns [oasis-open.org] , that didn't make it into TREX or Relax NG.

On balancing the simple specification with the rigorous mathematical model:

James Clark [oasis-open.org] wrote: I also don't think a description in terms of automata is a good for the spec, because it would require that the spec describe how to build an automata. I also want to keep things easy for people who aren't using automata to implement this.

Kohsuke KAWAGUCHI [oasis-open.org] wrote: I think the spec should describe constraints as currently it does, too. But I feel it should be based on a mathematical model, otherwise it will be unnecessarily ad hoc.

Murata Makoto [oasis-open.org] describes a difference between himself and James Clark:

You tend to think that no restrictions are easier to understand for users. On the other hand, I tend to think that tight restrictions are easier to understand for users.

James Clark [oasis-open.org] defines the TREX normal form, and Murata Makoto [oasis-open.org] agrees: I think that this normal form helps conversion to different languages. Is is also good for education.

Why is it called Relax NG [oasis-open.org] ?

Name change. James - blending of Relax/TREX name hard to do, but we don't want a completely new name [because it would suggest a proliferation of schema languages which we don't want]. James - I think we should go with Relax 2.0 or some adjective [or tag], don't like what "2.0" suggests though. M.-san - I like this. It will be easier to advance JIS/ISO specs. Josh - Relax .NET? K.-san - Relax++? James - Relax NG [Next Generation]?

I have to agree. (4, Insightful)

JanusFury (452699) | more than 7 years ago | (#17109006)

Has anyone here ever tried to read an XML schema for anything relatively complex? It's a nightmare. RELAX looks much cleaner and more direct, which I wholeheartedly approve of.

Re:I have to agree. (4, Interesting)

sien (35268) | more than 7 years ago | (#17109112)

Yes. I've done it using Relax NG [relaxng.org] and it was easy, simple and readable.

It also works really, really well with the nXML [thaiopensource.com] mode for emacs.

Finally, XML schemas in a way that are not verbose, ugly and unreadable. And if you do need one of the older schema languages there are translators from RelaxNG available.

Re:I have to agree. (4, Interesting)

radtea (464814) | more than 7 years ago | (#17109446)


I was at SGML '96 where XML was first announced, and was one of those people who went home and wrote a (non-validating) XML parser over the weekend, based on the draft spec. I've used both DTDs and XML Schemas and can say without question that schemas are actually a bigger pain to work with than DTDs. DTDs were bad enough, but schemas have been a major step backwards, adding complexity without adding the features one actually needs.

Some years ago I wrote a code generator that used DTDs as the data modelling language. I sold it to the company I was working for at the time and someone I had no control over re-wrote it use schemas because they were "simpler". The result had major bugs and dropped features, not entirely due to schema-related problems, although it is worth noting that the "simplifications" included handling schemas in completely incorrect ways, because if you handled them correctly they could not do the job. I created a new generator from scratch last year and tried to do thing "properly" with schemas. It was essentially impossible, and I wound up creating a custom XML-based language use as input.

At the time there was no Relax NG standards process, so I stayed clear of it. But it has the blessing of James Clarke too (author of the SP SGML parser and the expat XML parser.) So it is probably worth another very hard look.

MyXML scheme (sucks too) (1)

zitintheass (1005533) | more than 7 years ago | (#17109014)

May be I should post MY own ingenious scheme on Wikipedia and then proclaim international standard. Once I can claim the standard I will then be levitated into the high-earning circles in no time.., right?

Re:MyXML scheme (sucks too) (1, Funny)

Pulse_Instance (698417) | more than 7 years ago | (#17109494)

it would work but only if you express your idea like this
  1. Post ingenious scheme on Wikipedia
  2. Proclaim international standard
  3. ...
  4. Profit!!!

Just sit back... (0)

tubapro12 (896596) | more than 7 years ago | (#17109028)

...and RELAX thinking of the fact someone wants to change your standards. What kind of programmer can't use XML effectively anyhow...oh wait... (No, I didn't read TFA!)

Re:Just sit back... (4, Informative)

ubernostrum (219442) | more than 7 years ago | (#17109156)

What kind of programmer can't use XML effectively anyhow...oh wait... (No, I didn't read TFA!)

Helpful hint for understanding the above: Tim Bray, author of TFA, is one of the guys who originally developed and spec'd out XML. Really. His name's on the spec [w3.org] and everything. So if he says that a particular XML tool has problems, it's probably a good idea to take him at his word ;)

To the point. (2, Funny)

jhd (7165) | more than 7 years ago | (#17109030)

"W3C XML Schemas (XSD) suck"

Hey Tim, don't hold back, tell us what you really think.

Re:To the point. (0, Redundant)

bblboy54 (926265) | more than 7 years ago | (#17109860)

"W3C XML Schemas (XSD) suck"

Eventually I dont even see the code. All I see is blonde, brunette...... and the woman in the red dress, of course.

Leading, I mean leading.... (0)

dot.solipsist (895369) | more than 7 years ago | (#17109070)

Hey, Tim: p {line-height:1.7em;}, seriously.

it's a rather straightforward observation (0)

circletimessquare (444983) | more than 7 years ago | (#17109098)

if something, anything, is intended to be primarily parsed by human eyes, write it in c++/java style

if something, anything, is intended to be primarily parsed by machine, use xml

xml is a b**ch to read

Re:it's a rather straightforward observation (2, Insightful)

GroovinWithMrBloe (832127) | more than 7 years ago | (#17109122)

if something, anything, is intended to be primarily parsed by machine, use xml

xml is a b**ch to read
Don't forget what we used to use... binary is even worse. XML was designed with people in mind, which is why it's easier for people to read and manipulate than your traditional binary file format.

Re:it's a rather straightforward observation (2, Informative)

radtea (464814) | more than 7 years ago | (#17109468)

XML was designed with people in mind, which is why it's easier for people to read and manipulate than your traditional binary file format.

Err... no.

XML was a step back from SGML's "human-friendly" clever tricks. XML was intended to be easy to PARSE, not easy to read.

XML uses a binary format (4, Insightful)

ClosedSource (238333) | more than 7 years ago | (#17109550)

Of course ASCII (or UNICODE for that matter) is a binary standard as well. So special tools called text editors were created so that people could read it.

There are more sophisticated binary standards that are more efficient than ASCII and it wouldn't take a lot of effort to create viewers/editors for them as well. Of course most markup documents would be significantly smaller if tags didn't have to be S-P-E-L-L-E-D O-U-T character by character. Each HTML tag could be encoded in just two bytes with lots of room to spare.

It always fascinates me that we have no problem making customers use a new specialized tool like a browser, but it's taboo to use a non-ASCII tool for development. So we continue to structure our data as if it were going to be processed by a VT100.

Re:XML uses a binary format (1)

Al Dimond (792444) | more than 7 years ago | (#17109666)

I wish I hadn't used all my mod points earlier today, because that's an interesting post... it would be interesting to set up a programming environment with a binary format and specialized editor, though on second thought it might not work so well. ASCII text is very flexible and almost universally understood across different platforms. It's hard to imagine a non-text based paradigm for developing full programs that's as flexible, though there are certainly examples such as resource editors for GUI creation where graphical tools make life easier. Maybe non-text based programming would be good for rapid development. HyperCard largely used non-text interfaces for development, and the overall organization was certainly not based on text.

A "compiled" or specially crafted binary version of HTML/XML might work nicely, and could potentially save bandwith; lots of web pages are sent gzipped, but a specialized binary format should be able to get the size down even more.

Re:XML uses a binary format (0)

Anonymous Coward | more than 7 years ago | (#17111218)

The 3D design and animation software Maya essentially does this, standard files can be saved either in .ma (ASCII) or .mb (binary) formats and they are fully equivalent, with the main advantage of binary files being size and parse time.

Re:XML uses a binary format (3, Interesting)

2short (466733) | more than 7 years ago | (#17110172)


You could certainly make XML vastly more compact if you had some table of tags mapped to 2-byte codes. You're not the first to have such an idea, and I and others will be happy to use it... as soon as you've got it standardized, implemented, and as widely accepted as ASCII. Point being, I, and everyone I've never even met who will ever touch some particular XML file, already has a text editor.

We also all have some way of decompressing files in several standard compression formats, which will squash the XML down to the same size as your custom scheme, if storage space is an issue, which it generally isn't. There's all manner of custom schemes one can use to do various things better when one defines the platform. When you want to inter-opperate well, you need to use the capabilities that already exist on only semi-known systems.

Generally we don't actually make customers use new specialized tools. We take advantage of the new specialized tools they already have. I'm pretty sure not one of my customers ever got a browser to read my documentation; I wrote it in HTML because they've all got browsers already.

Re:XML uses a binary format (1)

quigonn (80360) | more than 7 years ago | (#17110722)

You could certainly make XML vastly more compact if you had some table of tags mapped to 2-byte codes. You're not the first to have such an idea, and I and others will be happy to use it... as soon as you've got it standardized, implemented, and as widely accepted as ASCII.

Not as widely accepted as ASCII, but standardized and implemented: WBXML [wikipedia.org]

Re:XML uses a binary format (1)

Tei (520358) | more than 7 years ago | (#17110846)

Well.. some people tried binary code. And failed. Maybe because you are wrong and non-text code is a horrible painfull idea.

Re:XML uses a binary format (1)

dkf (304284) | more than 7 years ago | (#17111160)

It always fascinates me that we have no problem making customers use a new specialized tool like a browser, but it's taboo to use a non-ASCII tool for development. So we continue to structure our data as if it were going to be processed by a VT100.
Having tried to do real programming with a graphical programming language (no, not just GUI layout!) and having tried to actually write said graphical programming language, I have come to the conclusion that graphical programming is really really hard. Any time you have a really tricky problem to do, there is nothing better than a textual language for doing it (there are some things you can do with mixed models, but they never quite manage to go to being fully graphical).

There is no reason to stick to ASCII though (full UNICODE works fine in practice) and the use of variable-width fonts can work too, or it would if people didn't assume fixed-width fonts in a massive amount of existing code. It's probably a bad idea to convey real information in the font though; approaches more like the auto-colorizing of most programmers' editors works better.

Re:XML uses a binary format (0)

Anonymous Coward | more than 7 years ago | (#17111186)

Of course most markup documents would be significantly smaller if tags didn't have to be S-P-E-L-L-E-D O-U-T character by character. Each HTML tag could be encoded in just two bytes with lots of room to spare.
man gzip

Re:it's a rather straightforward observation (4, Informative)

Peter Cooper (660482) | more than 7 years ago | (#17109180)

Check out YAML. [wikipedia.org]

Re:it's a rather straightforward observation (0)

Anonymous Coward | more than 7 years ago | (#17109300)

if something, anything, is intended to be primarily parsed by human eyes, write it in c++/java style

Or JSON, or YAML (with certain optional braces and brackets) .. all basically look the same

if something, anything, is intended to be primarily parsed by machine, use xml

Uhhh, no thanks. If it's mostly for machines, mostly text or numbers, but humans have to look at it occasionally, use S-expressions. If it's strictly for machines, use a field-oriented format, use something like this: (number of data elements):(length of data):(data):(length of data):(data).. (i.e., put the number of things first, in ASCII or binary, followed by the things, repeat as needed). This is probably the easiest to parse and work with, and basically has built-in overflow and underflow protection.

I honestly can't think of a situation where XML would be superior to any of these (except of course for the fact that people are FAMILIAR with it, but is that really a good reason to use it for an *internal* format? You can always translate back and forth with a more compact and/or reliable format).

Relax NG's compact non-XML syntax (2, Interesting)

SimHacker (180785) | more than 7 years ago | (#17109346)

Relax NG has a compact non-XML syntax. But C++/Java is a horrible syntax to use if you want a language to be readable and easy to understand. Since when was 17 levels of operator precedence [wikipedia.org] easy to understand? Of course any good programmer always uses parenthesis to avoid ambiguity, so why should a language have 17 levels of built-in ambiguity just to make it that much easier to make hard to find mistakes?

-Don

From my blog: Relax NG Compact Syntax: no to operator precedence, yes to annotations! [donhopkins.com]

James Clark [jclark.com] is a fucking genius! Hes the guy who wrote the Expat XML parser, works on Relax NG [oasis-open.org] , and does tons [jclark.com] of other important stuff. Relax NG is an ingeniously designed, elegant XML schema language based on regular expressions, which also has a compact, convenient non-xml syntax [oasis-open.org] .

I totally respect the way he throws down the gauntlet on operator precedence (take that you Perl and C++ weenies!):

There is no notion of operator precedence. It is an error for patterns to combine the |, &, , and - operators without using parentheses to make the grouping explicit. For example, foo | bar, baz is not allowed; instead, either (foo | bar), baz or foo | (bar, baz) must be used. A similar restriction applies to name classes and the use of the | and - operators. These restrictions are not expressed in the above EBNF but they are made explicit in the BNF in Section 1.

You can translate back and forth between Relax NG's XML and compact syntaxes with full fidelity, without losing any important information. Relax NG supports annotating the grammar with standard and custom namespaces, so you can add standard extensions and extra user defined meta-data to the grammar. That's useful for many applications like user interface generators, programming tools, editors, compilers, data binding, serialization, documentation, etc.

Here's an interesting example of a complex Relax NG application: OpenLaszlo [openlaszlo.com] is an XML/JavaScript based programming language, which the Laszlo compiler translates into SWF files for the Flash player. The Laszlo compiler and programming tools use this lzx.rnc Relax NG schema for the OpenLaszlo XML language [openlaszlo.org] . This schema contains annotations used by the Laslzo compiler to define the syntax and semantics of the XML based programming language.

The schema starts out by defining a few namespaces:

default namespace = "http://www.laszlosystems.com/2003/05/lzx"
namespace rng = "http://relaxng.org/ns/structure/1.0"
namespace a = "http://relaxng.org/ns/compatibility/annotations/1 .0"
datatypes xsd = "http://www.w3.org/2001/XMLSchema-datatypes"
namespace lza = "http://www.laszlosystems.com/annotations/1.0"

The a: namespace [oasis-open.org] defines some standard annotations like a:defaultValue, and the lza: namespace defines some custom annotations private to the Laszlo compiler like lza:visibility and lza:modifiers. Thanks to the ability to annotate the grammar, much of the syntax and semantics of the Laszlo programming language are defined directly in the Relax NG schema in the compact syntax, so any other tool can read the exact same definition the compiler is using!

To show how truly simple and elegant it is, here is the snake eating its tail: The Relax NG XML syntax, written in the Relax NG compact syntax:

# RELAX NG XML syntax specified in compact syntax.

default namespace rng = "http://relaxng.org/ns/structure/1.0"
namespace local = ""
datatypes xsd = "http://www.w3.org/2001/XMLSchema-datatypes"

start = pattern

pattern =
element element { (nameQName | nameClass), (common & pattern+) }
| element attribute { (nameQName | nameClass), (common & pattern?) }
| element group|interleave|choice|optional
|zeroOrMore|oneOrMore|list|mixed { common & pattern+ }
| element ref|parentRef { nameNCName, common }
| element empty|notAllowed|text { common }
| element data { type, param*, (common & exceptPattern?) }
| element value { commonAttributes, type?, xsd:string }
| element externalRef { href, common }
| element grammar { common & grammarContent* }

param = element param { commonAttributes, nameNCName, xsd:string }

exceptPattern = element except { common & pattern+ }

grammarContent =
definition
| element div { common & grammarContent* }
| element include { href, (common & includeContent*) }

includeContent =
definition
| element div { common & includeContent* }

definition =
element start { combine?, (common & pattern+) }
| element define { nameNCName, combine?, (common & pattern+) }

combine = attribute combine { "choice" | "interleave" }

nameClass =
element name { commonAttributes, xsd:QName }
| element anyName { common & exceptNameClass? }
| element nsName { common & exceptNameClass? }
| element choice { common & nameClass+ }

exceptNameClass = element except { common & nameClass+ }

nameQName = attribute name { xsd:QName }
nameNCName = attribute name { xsd:NCName }
href = attribute href { xsd:anyURI }
type = attribute type { xsd:NCName }

common = commonAttributes, foreignElement*

commonAttributes =
attribute ns { xsd:string }?,
attribute datatypeLibrary { xsd:anyURI }?,
foreignAttribute*

foreignElement = element * - rng:* { (anyAttribute | text | anyElement)* }
foreignAttribute = attribute * - (rng:*|local:*) { text }
anyElement = element * { (anyAttribute | text | anyElement)* }
anyAttribute = attribute * { text }

Re:Relax NG's compact non-XML syntax (2, Funny)

Anonymous Coward | more than 7 years ago | (#17109714)

Stop cutting and pasting from your fucking blog already. Make your point without it, or if you need to, then link to it.

20-year prediction (-1, Redundant)

Anonymous Coward | more than 7 years ago | (#17109782)

XML users will rediscover Lisp.

Re:20-year prediction (1)

SimHacker (180785) | more than 7 years ago | (#17110222)

I believe James Clark, who co-designed Relax/NG, understands and programs in Lisp pretty well (as well as Haskel, Java, C and many other languages). He helped design and implement DSSSL [jclark.com] (wikipedia article [wikipedia.org] ), which is based on Scheme, and led to XSLT [wikipedia.org] , which he also designed.

-Don

Re:Relax NG's compact non-XML syntax (1)

nagora (177841) | more than 7 years ago | (#17111130)

That's nice looking; basically BNF with some twiddles. That I can read; XML is just plain bad. I remember when it came out the first thing I ever said about it was "Why the hell didn't they use some type of BNF?". This is exactly the sort of thing I had in mind.

"Twiddles" is a technical term.

TWW

If it's not meant to be read by humans (1)

porkchop_d_clown (39923) | more than 7 years ago | (#17109376)

then why are you using an ASCII encoding in the first place? Those tags just lower the signal to noise ratio. Even Apple's given up and started saving their meta data in a "compiled" version of XML.

Oh, and, "Hi! How you doing? Long time no see!"

Re:it's a rather straightforward observation (1)

jomama717 (779243) | more than 7 years ago | (#17109380)

xml is a b**ch to read
Beats EDI [wikipedia.org] .

I'll take XML over a positional format any day, even if it only has to be looked at by human eyes 5% of the time. If you find yourself in a situation requiring eyeball examination of purchase order/shipping data at a large electronic commerce company it is likely an emergency and <ctrl>-f 'ing for a tag name, or using a web browser to check well-formedness can be a lifesaver.

Re:it's a rather straightforward observation (1)

Creosote (33182) | more than 7 years ago | (#17109390)

xml is a b**ch to read

Like any other formalism, it's difficult until you get used to it. The more familiar you are with a particular XML tagset and markup conventions, the easier it is to pick out the relevant structures and information. I remember being apalled at the verbosity of XSLT when I first begin to use it, but nowadays if I'm working with well structured XSLT code (and color-coding in the editor) I can scan it pretty efficiently.

That said, a non-XML syntax is almost always going to be more human-friendly. Which is another advantage of RELAX NG, of course, since it has a compact syntax that translates back and forth without loss of information to the XML form of the language.

XML Totally Sucks - All of it! (0, Troll)

l810c (551591) | more than 7 years ago | (#17109138)

I may be old school, working with flat files and all for over 20 years, but I do work with a lot of newer technology.

Every time I have to interface with with XML, I just groan.

It's extensible, rah rah.
It's self documented, rah rah.
rah rah blah blah

It's way over-hyped, unnecessary in most cases and way over used.

Give me a DB connection or a flat file, period.

Re:XML Totally Sucks - All of it! (2, Insightful)

beavis88 (25983) | more than 7 years ago | (#17109158)

And if you can't have a DB connection?

For flat data, sure a flat file is fine...for structured/hierarchical data, a flat file is :(

Re:XML Totally Sucks - All of it! (1, Flamebait)

unity100 (970058) | more than 7 years ago | (#17109236)

Why the hell would you ever have to use flat file or xml for data/hierarchy anyway ?

now even for little stuff we use freely available databases and small snippets.

Re:XML Totally Sucks - All of it! (1)

Nataku564 (668188) | more than 7 years ago | (#17109654)

Some companies have to interoperate with each other. And by some, I actually mean nearly all of them. Most of the data exchanged comes out of a database at some point, and as such, is naturally able to be put into a hierarchy with reasonable ease. XML, and similar formats, make this much less painful than if you had to flatten it out.

Where I currently work, I get data from several dozen other large companies. Most of it is not in XML. We generally have 2 people full time just on maintaining the parsers. If they were all in XML, the amount of maintainence required would be next to nothing.

Re:XML Totally Sucks - All of it! (1)

unity100 (970058) | more than 7 years ago | (#17110434)

well, if your company have developed a mutual interface for 12 companies at the start, then you wouldnt need to have people parsing the data to your database.

Re:XML Totally Sucks - All of it! (1)

l810c (551591) | more than 7 years ago | (#17109238)

You either need a Dataset or All of the data.

I can send you a Dataset for your application needs or I can send you All of the data in a series of flat files that you can then manipulate with code/import to relational database.

I reject the XML self documenting data paradigm, it's just not applicable to most business processes. You are relying on the originating XML document to follow your own in house rules.

I want my data clean and neat and then I work my magic with it.

Re:XML Totally Sucks - All of it! (1)

Nataku564 (668188) | more than 7 years ago | (#17109678)

This is exactly what DTDs and XSDs are there to take care of. Relying on the document to follow your own in house rules is the exact opposite of what you are supposed to do, in fact. The format document defines exactly what your parser should be doing/expecting, and if your data vendor doesn't respect that contract, its very easy to show who is in the wrong. With flat files, all I have to do is add an extra column and your parser will die. For one time imports this doesn't matter, but most business processes are not one time.

Re:XML Totally Sucks - All of it! (1)

l810c (551591) | more than 7 years ago | (#17110012)

The Sky is Blue!!!

Re:XML Totally Sucks - All of it! (0)

Anonymous Coward | more than 7 years ago | (#17109636)

> And if you can't have a DB connection?

Sqlite or Berkeley DB?

Re:XML Totally Sucks - All of it! (2, Insightful)

Anonymous Coward | more than 7 years ago | (#17109196)

XML would be great if people validated their XML files before sending them out. And cut the verbosity and redundancy down by 90%. And used english elements instead of numbers. Ahh XML, the ideal most people pay lip service to but up to which they fail to live.

Re:XML Totally Sucks - All of it! (2, Insightful)

pleb1024 (786643) | more than 7 years ago | (#17109352)

Totally agree.

While XML may have it's places (I've yet to encounter one in the commerical world), passing large amount of data is not one of them. A good flat file design is a lot more efficent than XML, and short of hardware accelartion I don't see that changing.

I'm currently trying to assist a customer, whose changing from one system to another, the current system generates flat files of approx 2gig in size every couple of days (billing data). The new system produces files of approx 13gig. The data contained within files result in the exact same bill being produced for the customers.

Needless to say, the extra diskspace (yes we do compress them), and processing time to parse/compress is such a waste.

In my mind, XML trades shorter development time / 'portability' (well so the theory goes), for greater resource usage (CPU/Disk), whereas most customers I've dealt with would rather take a little longer to develop, and have a lot less resource limitation issues on the production systems. The old methods of 'just throw more hardware at it' just don't work in the real world anymore.

Re:XML Totally Sucks - All of it! (4, Insightful)

Just Some Guy (3352) | more than 7 years ago | (#17109514)

While XML may have it's places (I've yet to encounter one in the commerical world), passing large amount of data is not one of them.

Yeah, well I have to look at EDI every day. I'd switch to XML in a heartbeat if it were up to me.

You picked some obvious strawmen to shoot down. XML isn't for building gigabyte databases (regardless of whether some people try to use it for that). It's for easily moving data between applications. If you think writing a flat text parser is easy, then you've never had to deal with nested data or escaped characters. Say what you will about XML, but it's nice to have one set standard that deals with all that, even if suboptimally, because I never want to write another ad-hoc parser for as long as I live. Been there, done that, have no desire to bother again.

Re:XML Totally Sucks - All of it! (0)

Anonymous Coward | more than 7 years ago | (#17109600)

> You picked some obvious strawmen to shoot down. XML isn't for building gigabyte databases (regardless of whether some people try to use it for that). It's for easily moving data between applications.

I think XML "is for" what its users happen to actually use it for, despite what it "should" be used for. And that often happens to be transferring multi-gigabyte dumps of database tables in some convoluted, verbose XML format. YEAIGH!

Re:XML Totally Sucks - All of it! (0)

mauddib~ (126018) | more than 7 years ago | (#17109684)

XML isn't for building gigabyte databases (regardless of whether some people try to use it for that).

But the world is about throwing loads and loads of data around. The problem with XML is that it works great individually, but breaks down to pieces when it has to cooperate with different data-formats. A simple binary format will do fine 99% of the time. It also leaves room open for subtle optimalizations in the way the data is send. In my view, XML only increases development time and decreases CPU utilization, memory utilization, network utilization and programmer utilization. It is a well trodden path right now:

1. Have no clue on how to solve simple world problems
2. Think of another format to describe the world/data/datadefinition/religion
3. ...
4. Profit!

(btw, somewhere in 3 you'll see that the state of the world goes back to state 1, but now with even faster/leaner/meaner machines)

Re:XML Totally Sucks - All of it! (0)

Anonymous Coward | more than 7 years ago | (#17109810)

XML is a standard. That's one of the good things going for it. On the other hand, it might have been better if the community had standardized around something a little less complicated and a little less bloated.

XML is like Electricity (4, Insightful)

SimHacker (180785) | more than 7 years ago | (#17110242)

It's good for transmitting information/energy, but it's not good for storing it.

-Don

COBOL Totally Rocks - All of it! (1, Funny)

Anonymous Coward | more than 7 years ago | (#17109420)

"I may be old school, working with flat files and all for over 20 years, but I do work with a lot of newer technology."

Well I'm your counterpart in India and I'm happy to hear you're having problems getting use to newer technologies. Keep up the good work.

Re:COBOL Totally Rocks - All of it! (1)

l810c (551591) | more than 7 years ago | (#17109556)

Who said COBOL?

Re:COBOL Totally Rocks - All of it! (1)

Gorshkov (932507) | more than 7 years ago | (#17110744)

Well I'm your counterpart in India and I'm happy to hear you're having problems getting use to newer technologies. Keep up the good work.
Aren't you the guy that linked in that buggy, unreliable 10 Gb library into our application so you could use that new, just-freshly-developed WAY cool highly optimized parallel recursive garbage-collecting sort routine to deal with an unordered list of 10 items?

Re:XML Totally Sucks - All of it! (0)

Anonymous Coward | more than 7 years ago | (#17110656)

you forgot the </rant> tags :(

I agree! (3, Funny)

Maddog787 (1021593) | more than 7 years ago | (#17109174)

I refuse to use XML in any shape way or form no matter what anyone say or does with it!!!

What should I click on? (0)

Anonymous Coward | more than 7 years ago | (#17109178)

Neat article, but it took me a few clicks to find it. Does anyone else find it supremely annoying how there are always a plenty of links in the story but you have to actually read the url's to find which one goes to the thing being discussed. How about a (-story-) link, or perhaps a different color of link for all those that rare just links to wikipedia (I can look it up myself, thanks). _____ , it's infuriating.

Like two peas in a pod (1)

KalElOfJorEl (998741) | more than 7 years ago | (#17109202)

Between this standard and REST, it looks like we have some very lazy web services, RESTing and RELAX NG all the time . . .

i read the title as.. (0, Offtopic)

middlemen (765373) | more than 7 years ago | (#17109322)

the first thing i did was misread the title as "Tim's bra says RELAX", then I reread it as "Tim Brays RELAX", ...

Telltale Sign... (1)

PipianJ (574459) | more than 7 years ago | (#17109364)

I've been picking up Emacs lately, and the xml-mode standardly used (nxml-mode) uses RELAX over XML Schema. I suspect that probably says a lot for RELAX's parseability. I've had just a little bit of experience playing around with Schemas and they seem about as navigable as DTDs, which is to say not very. I haven't tried RELAX though.

YUO FAIL It (-1)

Anonymous Coward | more than 7 years ago | (#17109382)

and co)ders [goat.cx]

Relax NG: Design-by-Inspired-Individuals (3, Interesting)

SimHacker (180785) | more than 7 years ago | (#17109388)

Relax NG is a great example of the triumph of Design-by-Inspired-Individuals vs. Design-by-Committee.

In The State of XML [xml.com] , Edd Dumbill explains the secret behind the success of Relax NG:

Incidentally the RELAX NG success can equally well be framed as a case of design-by-inspired-individuals vs. design-by-committee as much as it can be seen as a OASIS vs. W3C thing.

-Don

Re:Relax NG: Design-by-Inspired-Individuals (-1, Troll)

Anonymous Coward | more than 7 years ago | (#17109548)

Relax NG is a great example of the triumph of Design-by-Inspired-Individuals vs. Design-by-Committee.
You have an odd definition of "triumph". RNG is nothing but vain wheel re-inventing by not-invented-by-me blowhards. XSD is not perfect, but the schemas are not hard to read, write, or understand. RNG will be forgotten in five years. XSD will not.

Re:Relax NG: Design-by-Inspired-Individuals (0, Troll)

SimHacker (180785) | more than 7 years ago | (#17109700)

Do you have any idea who you're calling a "not-invented-by-me blowhard", and what else they've invented and written? You obviously have no idea what you're talking about. Learn your history and get your facts straight, before showing yourself to be a such an ignorant blowhard. If you had a leg to stand on, you wouldn't be afraid to post under your own name, troll.

Why do you have such hard feelings about RNG? Were you on the XSD committee??! Shame on you! Yuck! Bad dog.

-Don

Re:Relax NG: Design-by-Inspired-Individuals (-1, Troll)

Anonymous Coward | more than 7 years ago | (#17110048)

Do you have any idea who you're calling a "not-invented-by-me blowhard", and what else they've invented and written?
Why, yes, I do. Unlike you, I prefer to think for myself, rather than cow to supposed authority figures who can't frame a coherent argument for their biased opinions, particularly ones who've created a mess as ugly as XML and then go around bad mouthing the work of others.
Why do you have such hard feelings about RNG? Were you on the XSD committee??! Shame on you! Yuck! Bad dog.
I don't have "hard feelings" about RNG, nor have I been on an XSD committee. I do know pointless "not-invented-here" bullshit when I see it. XML is finally getting close to the point of being as useful as the standards it needlessly displaced. We're finally seeing good support for data binding tools--which is the primary reason for any of this technology to exist at all--and the last thing we need is to slow down progress due to ego-driven jihads.

Re:Relax NG: Design-by-Inspired-Individuals (1)

SimHacker (180785) | more than 7 years ago | (#17110158)

And you consider XSD to be progress??! You sound like George W Bush trying to put a good spin on Iraq. "Mission Accomplished!"

So how to you counter Tim Bray's arguments against XSD?

-Don

Re:Relax NG: Design-by-Inspired-Individuals (0)

Anonymous Coward | more than 7 years ago | (#17110290)

And you consider XSD to be progress??!
XSD is sure as hell progress over DTDs, which I'll admit doesn't say much in itself, because DTDs are worthless crap. Gee, who was it that brought us XML DTDs again?
You sound like George W Bush trying to put a good spin on Iraq. "Mission Accomplished!"
Last time I checked, XSD was successfully being used in a large number of specifications used in the real world. That is success, and it is hardly analogous to the situation in Iraq.
So how to you counter Tim Bray's arguments against XSD?
How would you suggest it's even possible to counter purely subjective arguments like XSD is "hard to read, hard to write, hard to understand". It's pure opinion, and it's also bullshit. RNG and XSD just are not that different.

Frankie says ... (-1, Redundant)

cjjjer (530715) | more than 7 years ago | (#17109406)

RELAX Tim ....

Doesn't Matter Either Way (0)

Anonymous Coward | more than 7 years ago | (#17109440)

XML is a compromise between human readability and machine readability.

If you want data to be human readable, then use a nice interface with data fields in the right places and functions for accessibility. (I would say "GUI", but a front-end isn't necessarily graphical.) Just the idea of a sequential stream of data sucks for human introspection and/or modification.

If you want data to be machine readable, then make it a flat binary file. A memory dump that you can mmap(), essentially. Having to parse/serialize sucks, from a programmer's point of view.

XML is a compromise between the two. It doesn't fit either mandates well. It is not easily human readable (try to shove it in the face of the average user), and it is not easily machine readable (bulky, slow to parse and generate).

However, XML is great for:

  • Interoperability, when you suddenly find out that your flat mmap'ed file doesn't work across heterogeneous systems.
  • Extensibility, because you can rather easily support prior file versions if you do your design correctly. And you can make some fields optional.
  • Structure. Having to write a schema or relax grammar or an UML diagram forces you to think about the structure of your data before you start filling in global variables in your code.
Also, with a schema or grammar at hand, it can be useful to just shove files at a validating parser.

But just having a schema or grammar for its data does not make any application magically interoperable. Without a good documentation, an XML file is just as binary as before. Or how else should I know what a <fooStuff> tag does.

A good schema or grammar can go a long way to augment documentation (of data files for interoperability purposes), but it is no replacement for it.

Just my 2 cents.

Great job, now to clean up XML itself (2, Insightful)

iamacat (583406) | more than 7 years ago | (#17109452)

With a notation similar to RELAX NG compact syntax. XML has been a killer of readable formats like windows-style ini files. It tries to be readable by both human and machine and succeeds at neither. It's like programming in assembler, because it can be read by a human better than machine code and compiled faster than C.

Re:Great job, now to clean up XML itself (3, Insightful)

killjoe (766577) | more than 7 years ago | (#17109688)

I believe you are looking for lisp. It's XML cleaned up, simplified and hulkified.

Re:Great job, now to clean up XML itself (1)

iamacat (583406) | more than 7 years ago | (#17110698)

LISP -> XML alternative == Postscript -> PDF. You don't always want to execute your data, especially with today's abundance of malware.

One fix to XML I'd like to have... (1)

Reality Master 101 (179095) | more than 7 years ago | (#17109492)

Speaking of XML, how much smaller would XML files be if they made one minor simple change...

Add to mean "close the matching element".

*sigh* I wish I'd been on the committee when they specified the standard.

Re:One fix to XML I'd like to have... (2, Interesting)

Reality Master 101 (179095) | more than 7 years ago | (#17109528)

Damn! I mean, add </>...

(Argh, the "wait between comments" thing is infuriating...)

Re:One fix to XML I'd like to have... (4, Insightful)

nuzak (959558) | more than 7 years ago | (#17109598)

That feature is in SGML. In fact it can be even shorter than that, you can express an entire tag and its content with <tag/content goes here/ (even the ending > is optional). SGML even lets you change the angle brackets to anything else you want. You can make any SGML doc look like nothing you or anyone else has ever seen ... all part of the feature set.

SGML is full of fun little hacks like that, and it was a pain in the ass to read. Omitting the tag name from the end tag makes it impossible to know you have an improperly closed tag til the end of the document, and then you have no idea which tag wasn't closed. And no, that wasn't a theoretical problem either, this became a real problem with giant SGML docs that used all the shortcuts.

If you really hate XML's verbosity so much, realize that it was designed for easy reading, not easy writing. I whipped up my own xml mode in emacs and made '</' trigger an "electric-slash" behavior that closes the tag automatically. Not rocket science.

Re:One fix to XML I'd like to have... (1)

tbray (95102) | more than 7 years ago | (#17110416)

Heh, my own tagged-text mode uses just '/' to mean "close whatever needs closing". Works great. (control-/ if yoiu want a real /).

Re:One fix to XML I'd like to have... (1)

horster (516139) | more than 7 years ago | (#17109558)

totally agree...

Re:One fix to XML I'd like to have... (1)

Electrum (94638) | more than 7 years ago | (#17109856)

Speaking of XML, how much smaller would XML files be if they made one minor simple change...

Add to mean "close the matching element".


You mean like Lisp [defmacro.org] S-expressions [wikipedia.org] ?

<copy>
    <todir>../new/dir</todir>
    <fileset>
        <dir>src_dir</dir>
    </fileset>
</copy>
 
(copy
  (todir "../new/dir")
  (fileset (dir "src_dir")))

Re:One fix to XML I'd like to have... (1)

Nasarius (593729) | more than 7 years ago | (#17109888)

If file size is a concern, XML compresses easily. The OpenOffice file formats are zipped XML.

why don't we just keep using DTDs? (0)

Anonymous Coward | more than 7 years ago | (#17109580)

Simple, readable, concise. Ah, but not XML-like, maybe because they are simple, readable, and concise.

XML nightmare (4, Insightful)

rgaginol (950787) | more than 7 years ago | (#17109614)

If XML Schema was a work colleague they would be Wally from Dilbert - it's not that things are impossible to do with it, it's just that the relative simple things become hard and the complex almost impossible. Due to the fact that almost anything is possible with XML schema with enough work (weeks, months years...) instead of just scrapping it, people keep at it doggedly despite the number of times we get bitten. I'd love to see the community move more completely to RELAX NG if it makes my life easier.

XSD: "Mission Accomplished!" (3, Funny)

SimHacker (180785) | more than 7 years ago | (#17109660)

From the xml-dev [xml.org] mailing list:

From: Rick Jelliffe
To: xml-dev@lists.xml.org
Date: Wed, 29 Nov 2006 12:46:06 +1100

Robert Koberg wrote:

I wonder if the people who think RNG won have "Re-elect Gore" bumper stickers...

Maybe a better analogy would be that the people who say that XSD is lovely is Mr Bush's "Mission Accomplished!"

Though of course there are differences between Iraq and XSD. One seems to be about people with their own fiefdom agendas stubbornly miring us in a quagmire, using a grabbag of thin reasons to justify it, denying any evidence that things are not rosy, perpetually promising that things are turning around, and enmeshing all sorts of decent people in a life of horror, difficulty and with no confidence in accomplishing the mission. The other is in the Middle East.

Just joking...
Rick

Slashdot Tags (1)

sc0p3 (972992) | more than 7 years ago | (#17109766)

Slashdot tags are officially useless. Who the hell is going to search for "dontdoit" when looking for this article.

Re:Slashdot Tags (1)

Mr2001 (90979) | more than 7 years ago | (#17109852)

Or "sharks" when looking for any article about lasers. Or "itsatrap"/"fud" when looking for any article about anything. We need a way to moderate tags.

Re:Slashdot Tags (1)

jZnat (793348) | more than 7 years ago | (#17110676)

Well, you can be sure that most articles tagged with "sharks" is actually about lasers, and articles tagged with "itsatrap" are probably about Microsoft.

Re:Slashdot Tags (1)

An ominous Cow art (320322) | more than 7 years ago | (#17109884)

Relax. :-)

Relax NG. (1)

miguel (7116) | more than 7 years ago | (#17109864)

Mono has complete support for RelaxNG in the form of the Commons.Xml.Relaxng assembly.

In addition to RelaxNG, it provides NVDL and RNC support.

Re:Relax NG. (2, Funny)

SeaFox (739806) | more than 7 years ago | (#17109906)

Mono has complete support for RelaxNG in the form of the Commons.Xml.Relaxng assembly.

So should the lesson here be to "RELAX if you have MONO"?

Relax NG - constraining based on attribute values (1)

SashaMan (263632) | more than 7 years ago | (#17109892)

As someone who has used XML schemas pretty extensively, I was pretty amazed at how I was able to skim through the tutorial in about 10 minutes and understand Relax NG, versus reading an entire XML Schema book and still needing to refer to it whenever I write schemas.

One thing I really like about Relax NG is that it's possible (with very easy syntax) to constrain the XML structure based on an attribute value, something you can't do in schema or a DTD. For example, suppose you want to have an XML element:

true
'
With Relax NG it's possible to constrain the text in the arg element (e.g. "true" or "false") based on the value of the type attribute. For example, if type="int", you could limit the text in arg to an integer value. This is something you can't do in schemas or dtds.

Why just RELAX when you can REST too? (1)

SuperKendall (25149) | more than 7 years ago | (#17110144)

Since you are simplifying your life by making the schema for web requests simpler, why not go all the way, ditch SOAP, and embrace REST [xfront.com] for XML-over-HTTP communications?

I call this the LineOfView (as in PoV) Problem (4, Insightful)

Qbertino (265505) | more than 7 years ago | (#17110450)

I call this the Line of View (as in PoV) or 'Horizon' Problem. The general problem is this: In XML we've got a standard that is universal for displaying n-dimensional structures in a basically 1-dimensional enviroment. (For the time being, we're ignoring that XML text ususally goes from left to right and top to bottom, making that something 2D to look at)
The question now is: where do you draw the line of view? Along which line do I take my knife to cut open my n-dimensional structure to unravel it and flatten it out into a 1-dimesional string of characters? This is a problem that is impossible to solve satisfactory for all possible PoVs or - as I say - Lines of View, or better yet, Horizons to the structure. Will I unravel my DB of books by authors? By issues? By vendors? By publishers or by weight and size? ... At some point you will have to look at in which way you want to handle your stuff and which way you're going to unravel it. This will undoubtly influence on how much XML clutter you will have to construct. With XML it's the same as with databases: It/they will allways be pathetic crutches for us to latch on to the real work. Undispensable, but crutches nontheless.

What I'm getting to is this: mapping n-dimensional stuff to 1-dimensional structures will allways suck one way or the other. It's just that with XML we all start agreeing upon in which way it's supposed to suck. I don't think that changing the Schema standard (or worse: introducing additional standards) will actually attack this hard problem. I have a strong suspicion that Relax NGs relief is illusional, short term and re-introduces downsides that XML Schema allready has takled with it's pesky and strict nature. For one it would be consistency with the View-Horizon once chosen all the way through the given data-structure. I don't know for shure - go test and find out - but I do know that universal serialization will allways come with downsides and RelaxNG (or any other schema) won't change that.

Re:I call this the LineOfView (as in PoV) Problem (1)

julesh (229690) | more than 7 years ago | (#17111062)

I think your problem is that you're using XML to perform the job of a relational database.

Not all tasks can be solved with the same tools.

Wait wait wait (1)

bytesex (112972) | more than 7 years ago | (#17110748)

This guy claims that this:

<element name="addressBook" xmlns="http://relaxng.org/ns/structure/1.0">
  <zeroOrMore>
    <element name="card">
      <element name="name">
        <text/>
      </element>
      <element name="email">
        <text/>
      </element>
    </element>
  </zeroOrMore>
</element>

is easier to read than this:

<!DOCTYPE addressBook [
<!ELEMENT addressBook (card*)>
<!ELEMENT card (name, email)>
<!ELEMENT name (#PCDATA)>
<!ELEMENT email (#PCDATA)>
]>

WTF ?!

Re:Wait wait wait (0)

Anonymous Coward | more than 7 years ago | (#17110980)

Well, if you think RELAX NG is ugly, take a look at Schema :P

DTD is fairly simple compared to other validation languages though.

Relax NG experiences (1)

Tim12s (209786) | more than 7 years ago | (#17110866)

I have enough experience with Relax NG to say that it is great.

The compact syntax is enjoyable as you can be quite precise (compared to XSD) and there are tools that convert between the compact syntax and the xml Relax NG syntax allowing you to use syntax that suites your needs. In general, JING it is quite a bit quicker than a few of the XSD validators for comparably complex schemas.

There are a few disadvantages:

* The full range of tools that are available are not advanced on a regular basis. I found a few bugs in the JING source code and had the opportunity to fix them where necessary.

* I feel that RelaxNG is marginalized because of XSD and along with that goes alot of additional OSS support. They are maintained by individuals instead of teams. I would recommend that the author of JING puts his software forward to the apache foundation (jakarta commons) and see if it can attract a bit more attention.

* Web services are a bit of a sticking point. The use of a Relax NG schema can be embedded into the WSDL, however, the various 3rd party clients may not necessarily understand the schema, and by extension, they would not generate any supporting classes making integration with a relax NG defined webservice a little more complex than it needs to be.

Relax NG really is great.

-Tim

RELAX compact syntax = BNF notation (1)

master_p (608214) | more than 7 years ago | (#17111352)

I don't see why XML schemas has to exist. BNF notation serves the exact same purpose: it describes a grammar. A BNF-like derivative is more than enough to define XML schemas. The compact syntax of RELAX NG is just that, and a bright idea.

It is really annoying when CS has to be discovered all over again. The problem of validating text to a certain format has been solved many decades ago, and BNF and variations of are known from the 60s...
 
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?