Subject: Re: The horror that is XML From: Erik Naggum <email@example.com> Date: Tue, 05 Mar 2002 16:20:55 GMT Newsgroups: comp.lang.lisp Message-ID: <firstname.lastname@example.org> * Tim Bradshaw | So really, I guess what I'm asking is: am I missing something really | obvious here, or is it all really just a very hard and over-complex | solution to a problem I've already solved? XML, being the single suckiest syntactic invention in the history of mankind, offers you several layers at which you can do exactly the same thing very differently, in fact so differently that it takes effort to see that they are even related. <foo type="bar">zot</foo> actually defines three different views on the same thing: Whather what you are really after is foo, bar, or zot, depends on your application. XML is only a overly complex and otherwise meaningless exercise in syntactic noise around the message you want to send. Its notion of "structure" must be regarded as the same kind of useless baggage that come with language that have been designed by people who have completely failed to understand what syntax is all about. It is therefore a mistake to try to shoe-horn things into the "structure" that XML allows you to define. In the abaove example, foo can be the application-level element, or it can be the syntax-level element and bar the application-level element. It is important to realize that SGML and XML offer a means to control only the generic identifier (foo) and their nesting, but that it is often important to use another attribute for the application. This was part of the reason for #FIXED in the attribute default specification and the purpose of omitting attributes from the actual tags. In my view, this is probably the only actually useful role that attributes can play, but there are other, much more elegant, ways to accomplish the same goal, but not within the SGML framework. Now, whether you use one of the parts of the markup, or use the contents of an element for your application is another design choice. The markup may only be useful for validation purposes, anyway. Let me illustrate: <if><condition>...</condition> <then>...</then> <else>...</else> </if> The XML now contains all the syntax information of the "host" language. Many people think this is the _only_ granularity at which XML should be used, and they try to enforce as much structure as possible, which generally produces completely useless results and so brittle "documents" that they break as soon as anyone gets any idea at all for improvement. <form operator="if"><form operator=... role="condition">...</form> <form operator=... role="then">...</form> <form operator=... role="else">...</form> </form> The XML now contains only a "surface level" syntax and the meaning of the form elements is determined by the application, which discards or ignores the "form" element completely and looks only at the attributes. This way of doing things allows for some interesting extensibility that XML cannot do on its own, and for which XML was designed because people used SGML wrong, as in the first example. <form>if<form>...condition...</form> <form>...then...</form> <form>...else...</form> </form> The XML is now only a suger-coating of syntax and the meaning of the entire construct is determined by the contents of the form elements, which are completely irrelevant after they have been parsed into a tree structure, which is very close to what we do with the parentheses in Common Lisp. I hope this can resolve some of the problems of being forced to use XML, but in all likelihood, lots of people will object to anything but the finest granularity, even though it renders their use of XML so complex that their applications will generally fail to be useful at all. Such is the curse of a literally meaningless syntactic contraption whose verbosity is so enormous that people are loath to use simple solutions. My preferred syntax these days is one where I use angle brackets instead of parentheses and let the symbol in the first position determines the parsing rules for the rest of that "form". It could be mistaken for XML if you are completely clueless, but then again, if you had any clue, you would not be using XML. /// -- In a fight against something, the fight has value, victory has none. In a fight for something, the fight is a loss, victory merely relief.