From ... Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!newshunter!cosy.sbg.ac.at!newsfeed.Austria.EU.net!newsfeed.kpnqwest.at!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: <3224504693262432@naggum.net> <3C88762A.31A729D5@hotmail.com> <3C89A3BB.588DC1E3@nyc.rr.com> Mail-Copies-To: never From: Erik Naggum Message-ID: <3224680700427395@naggum.net> Organization: Naggum Software, Oslo, Norway Lines: 47 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 09 Mar 2002 16:38:15 GMT X-Complaints-To: newsmaster@KPNQwest.no X-Trace: nreader1.kpnqwest.net 1015691895 193.71.199.50 (Sat, 09 Mar 2002 17:38:15 MET) NNTP-Posting-Date: Sat, 09 Mar 2002 17:38:15 MET Xref: archiver1.google.com comp.lang.lisp:28257 * Kenny Tilton | Is there anyone here who thinks they cannot /generate/ legal XML? (cake) | | Is there anyone here with a requirement to /read/ legal but otherwise | unspecified XML? (ouch) | | Is anyone aware of a standardized domain-specific XML representation | that is unreadable by an app to which the domain-specific XML | representation is known? (not) | | These are /my/ sticking points in this discussion. I do not think I | could read arbitrary XML, nor do I think arbitrary XML is meant to be | readable. That's why folks in different domains are standardizing. | (hello?) I have some problem getting at your rhetorical style, but it seems that you are not arguing, only positing and stipulating. There are _many_ people who cannot generate valid (legal is something else :) XML if their life depends on it. The problem is the moronic DTD and/or schema cruft. Getting both of these right is a nightmare that the people who could have been trained for it do not want to do and those who do it are not trained to handle that kind of programmer-level design. XML _is_ readable without having a DTD and having a clue what the data "means" -- that was the primary design goal. The problem with SGML was that you would not know whether some element had CDATA or RCDATA declared contents, meaning that only an end-tag would be recognized (and it better be for the only open element, in the spirit of redundant redundancy), not a start-tag for some other element, which would throw a naive parser off, as well as a lot of other minor stateful parsing problems. The parsability of arbitrary XML is such an obvious design goal of XML that I really wonder how you arrived at your last paragraph. It is completely bogus as a rationale for standardizing elements and their structural relationship, too. What people are standardizing in XML is the same they standardize with EDIFACT or systematized nomenclature for medicine (SNOMED) or even such "simple" things as the call letters of ships, airplanes, airports, radio and TV stations, etc. People tend to want to standardize sematnics, and leave syntax to randomness. XML is standardized randomness and might therefore be chosen as the preferred random way of expressing someone's semantic constructs. /// -- 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.