Tim Bray Says RELAX 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."
Don't do it. (Score:4, Funny)
Re: (Score:2, Funny)
Re: (Score:2)
Re: (Score:2)
Couldn't agree more (Score:5, Insightful)
On the other hand, RELAX NG "just works".
(all IME of course...:)
ant.
Re: (Score:3, Funny)
Re: (Score:2)
Your comment is even funnier with your sig: "Wake up, Zeke! The day ain't gonna waste itself."
Maximizing Composability and Relax NG Trivia (Score:5, Informative)
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:
Clark [oasis-open.org] describes the derivative algorithm's lazy approach to automaton construction:
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, weighin
Re: (Score:2, Funny)
Someone needs a dictionary.com link (Score:2)
Re: (Score:2)
Re: (Score:3, Informative)
For many problem domains, it often doesn't matter what language you throw up against Haskell -- the Haskell program will often be smaller by one or more orders of magnitude (for a sufficiently rich/interesting program, anyways). The grandparent poster didn't even craft the example in question; Java was just the vicitm-elect of this particular case. I'll observe that even if the Java program there could be made sho
Re: (Score:2, Insightful)
"This document does not describe any algorithms for transforming a RELAX NG schema into simplified form, nor for determining whether a RELAX NG schema is correct."
From the Jing implementation:
"This version of Jing implements:
* RELAX NG 1.0 Specification,
* RELAX NG Compact Syntax, and
* parts of RELAX NG DTD Compatibility, specifically checking of ID/IDREF/IDREFS."
also from the Jing implement
Re: (Score:2)
To be fair, this may be due to someone more familiar with Haskell trying to port their implementation to Java, rather than a native Java implementation being required to simulate those features. I don't know the history of those two implementations, but the fact that the Java implementation tries to simu
I have to agree. (Score:4, Insightful)
Re:I have to agree. (Score:5, Interesting)
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. (Score:5, Interesting)
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.
Re: (Score:2)
I was at SGML '96 where XML was first announced
Was that at some hotel in Swindon, UK? If so then I was there as well, if not then it must have been very shortly after the announcement, as XML (along with XSL) dominated the meeting. When XSL was described by a heavily bearded academic guy, several of the audience members became apoplectic. Apparently they thought DSSSL was a better alternative, something that amused me as all the DSSL tools I was aware of were either incomplete or as fiddly as fuck to wo
Re: (Score:2)
No, It was in Boston. The original XML spec was a 20 page booklet. One tidbit: This was at the height of the browser wars and MS was all gung-ho for XML while Netscape wanted nothing to do with it. Many of the SGML gurus were quietly rooting for MS for just that reason.
To the point. (Score:2, Funny)
Hey Tim, don't hold back, tell us what you really think.
I agree! (Score:3, Funny)
Telltale Sign... (Score:2)
Relax NG: Design-by-Inspired-Individuals (Score:4, Interesting)
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:
-Don
Re: (Score:2)
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: (Score:2)
Great job, now to clean up XML itself (Score:3, Insightful)
Re:Great job, now to clean up XML itself (Score:4, Insightful)
Re: (Score:2)
Re: (Score:2)
You might want to set up your own READ macros as well, to ensure that nobody uses #. maliciously.
Re: (Score:2)
Re: (Score:2)
Bare S-expressions don't define enough semantics to do what XML does; Lisp goes to far for what XML is used for in being a full programming language (though, given all the XML-related technologies that are widely used to add more and more programming-like features to XML, it may not be "too far"); somewhere between
XML (Score:2)
Not Lisp, but S-expressions, which are the basis of Lisp syntax; Lisp is an "application" of S-expressions, the same as XML applications are applications of XML. S-expressions extended with something similar to XMLs encoding declarations could substitute for XML and would be arguably cleaner—certainly, cleaner to Lispers, though I'm not so sure that:
(foo
(bar baz (spam: "eggs"))
is really more readable (rath
One fix to XML I'd like to have... (Score:2)
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: (Score:3, Interesting)
Damn! I mean, add </>...
(Argh, the "wait between comments" thing is infuriating...)
Re:One fix to XML I'd like to have... (Score:5, Insightful)
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: (Score:2)
Re: (Score:2)
Re: (Score:2)
Add to mean "close the matching element".
You mean like Lisp [defmacro.org] S-expressions [wikipedia.org]?
Re: (Score:2)
Re: (Score:2)
XML is basically a bloated way of expressing S-expressions. More compact (i.e. easy to parse, and small to store) versions already exist. What is really needed is a storage format that allows branches to be parsed in parallel. XML is inherently sequential; I have to parse an entire branch to know where the next one starts. It would be nice if I could scan ahead quickly and to the next branch at the same depth and parse this at t
XML nightmare (Score:4, Insightful)
XSD: "Mission Accomplished!" (Score:4, Funny)
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:
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
Relax NG. (Score:2)
In addition to RelaxNG, it provides NVDL and RNC support.
Re: (Score:3, Funny)
So should the lesson here be to "RELAX if you have MONO"?
Why just RELAX when you can REST too? (Score:2)
I call this the LineOfView (as in PoV) Problem (Score:5, Insightful)
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?
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: (Score:2)
Not all tasks can be solved with the same tools.
RELAX compact syntax = BNF notation (Score:2)
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...
Re: (Score:2)
But BNFs by their nature don't have a formal means to differentiate between syntactic rules that defi
Unfortunately, there is no automatic fetching.... (Score:2)
I agree that RelaxNG is much easier to read, and it will much more completely describe a grammar than will the other standard - and MUCH more completely define it than will a DTD.
Unfortunately, as far as I can tell there is no way to, within an XML document, state "Use THIS RelaxNG schema file to validate this document", as you can with a DTD. Thus, even if I have placed my RelaxNG schema on my web server, I cannot set things up such that (for example) libXML2 can automatically fe
Polishing a turd (Score:2)
Do we lose anything other than bandwidth use by doing this,
<tagNameThatCanBeLong>Some Text</>
instead of this:
<tagNameThatCanBeLong>Some Text</tagNameThatCanBeLong>
If the next end tag must belong to the last start tag what's the point of nami
Re: (Score:2)
I've been writing configuration files like that for years, and it works great. The only time I really want tags anyhow is when nesting stuff... and if you live in corporate IT land, you'll realize that doesn't actually happen because people who specify XML configuration files don't usually understand that a container is something that could hold things other than whisky and so forth.
Re: (Score:2, Insightful)
xml is a b**ch to read
Re: (Score:3, Informative)
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.
Re: (Score:2)
XML was intended to be easy to PARSE, not easy to read.
Correct, XML is slightly easier to parse because of explicit end tags but most people disabled short tag support and enforced end tags in SGML anyway (in the syntax declaration and DTD respectively). However, saying that XML is not as easy to read as SGML is stretching things a bit - I find them to have the same legibility, although when using namespaces in XML I find they tend to result in long tag names that obscure things a bit. The things that a
Re: (Score:2)
Reading XML is like reading compiled code. You might have to do it to debug something or to grok how the code works but XML is intended to be parsed, not read.
It seems to me that emphasis should be placed on features that improve parsing, not human readability. I don't know enough about XML or RELAX NG to opine on which is best for parsing but it seems that parsing should be the main criteria of which is "best".
XML uses a binary format (Score:5, Insightful)
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: (Score:2)
Re: (Score:2)
There's always the APL programming language [wikipedia.org] - just about every mathematical function call is mapped to a single unicode character.
Re: (Score:2)
Given how fast browsers were adopted by almost all platforms suggests to me that resisting binary formats is primarily a cultural issue among programmers than rather than a technical or practical one. I come from an embedded background, so it's not a problem for me.
Re:XML uses a binary format (Score:4, Interesting)
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: (Score:2)
Not as widely accepted as ASCII, but standardized and implemented: WBXML [wikipedia.org]
Re: (Score:2)
I used to entertain this idea as well. But then it occurred to me, that it is almost the same thing if you simply zip the XML code, using a compression program such as zip, gzip, or bzip2.
If you read up on how these lossless compression algorithms work, essentially they go through the input and built up an "index" of repeated strings. That is, any sequence of characters found to be repeated is placed in th
Re: (Score:2)
Which is basically what I was trying to say with my second paragraph. Everyone can handle zip-compressed XML right now, so a custom scheme would have to offer a big advantage over that to get anywhere, and it won't. As for CPU-friendliness; it's a non-issue. The average PC out there has a CPU that can decompress a zip file faster it can be read off that same PCs disk, let alone downloaded over a net connection; and that gap is widening. In the coding I do with very large amounts of data, we regularly c
Re: (Score:2)
Certainly, for most applications, the CPU thing is a non-issue.
Re: (Score:2)
You're missing the point. Until about a decade ago almost nobody had a browser.
Re: (Score:2)
I'm not missing the point. When most people didn't have browsers, I didn't write my documentation in HTML, and it would have been silly to ask me to, becasue people couldn't read it.
Today, it is silly to ask me to encode my data in a custom format that hasn't been widely adopted if I want others to be able to manipulate it. Maybe one such custom-xml-compression schemes will get widely adopted; and then I'll start using it. But today I'm going to go with zip-compressed XML, because people can read it.
It's
Re: (Score:2)
Re: (Score:2)
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 yo
Re: (Score:2)
Re: (Score:2)
For those who don't know: ASN.1 (Abstract Syntax Notation 1) is an ISO syntax notation which I believe was developed for defining packets and other stuff used in the OSI standards suite. It is also used in many popular Internet protocols and standards, such as Z39.50 (WAIS), SNMP, LDAP and PKI. (Just to mention a few.)
There are a few different encoding rules (mappings to binary), and I suppose a readable encoding - even an XML-like encoding - would be possible, although I don
Re: (Score:2)
2. Broswers don't accept zipped pages, so the file would have to be manually unzipped before presentation to the broswer.
3. Broswers could be modified for either a binary HTML or to accept a zipped page, but there would be more run-time processing involved to unzip than there would be to natively support a binary HTML.
Re: (Score:2)
Re:it's a rather straightforward observation (Score:5, Informative)
Relax NG's compact non-XML syntax (Score:2, Interesting)
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]
Jame [jclark.com]
Re: (Score:2, Funny)
Re: (Score:2)
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
If it's not meant to be read by humans (Score:2)
Oh, and, "Hi! How you doing? Long time no see!"
Re: (Score:2)
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 hum
Re:Just sit back... (Score:5, Informative)
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 ;)
Re: (Score:3, Insightful)
For flat data, sure a flat file is fine...for structured/hierarchical data, a flat file is
Re: (Score:2, Flamebait)
now even for little stuff we use freely available databases and small snippets.
Re: (Score:2)
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 parse
Re: (Score:2)
Re: (Score:2)
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: (Score:2)
Re: (Score:2)
Re: (Score:2, Insightful)
Re: (Score:2, Insightful)
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 con
Re:XML Totally Sucks - All of it! (Score:5, Insightful)
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.
XML is like Electricity (Score:5, Insightful)
It's good for transmitting information/energy, but it's not good for storing it.
-Don
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
What do you expect? Schemas were a Microsoft initiative IIRC.
Re: (Score:2)