From ...
Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed00.sul.t-online.de!t-online.de!newsfeed.esat.net!nslave.kpnqwest.net!nloc.kpnqwest.net!nmaster.kpnqwest.net!nreader1.kpnqwest.net.POSTED!not-for-mail
Newsgroups: comp.lang.lisp
Subject: Re: The horror that is XML
References: <ey3y9h7hgft.fsf@cley.com>
Mail-Copies-To: never
From: Erik Naggum <erik@naggum.net>
Message-ID: <3224334063725870@naggum.net>
Organization: Naggum Software, Oslo, Norway
Lines: 87
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 05 Mar 2002 16:20:55 GMT
X-Complaints-To: newsmaster@KPNQwest.no
X-Trace: nreader1.kpnqwest.net 1015345255 193.71.199.50 (Tue, 05 Mar 2002 17:20:55 MET)
NNTP-Posting-Date: Tue, 05 Mar 2002 17:20:55 MET
Xref: archiver1.google.com comp.lang.lisp:27819

* 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.