OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] What is XML For?

[ Lists Home | Date Index | Thread Index ]

On Tuesday 29 October 2002 16:20, Paul Prescod wrote:
> Alaric Snell wrote:
> > On Monday 28 October 2002 4:12 pm, Paul Prescod wrote:
> >...
> >
> >>>Because XML has a fragile data model, designed for publishing stuff to a
> >>>browser rather than transfer between applications?
> >>
> >>XML is based on SGML which was invented long before browsers as we know
> >>them.
> >
> > Yep, but that's orthogonal to my point; XML is based on ASCII, which is
> > based on binary, which has been around since (potentially) ancient times
> > in China (there being some evidence of binary arithmetic in certain
> > ancient Chinese symbolism).
> Argh. The XML _data model_ is not, as far as I know, much different than
> the implicit SGML "data model" which long predated browsers. If you
> believe that XML has a much "weaker" data model than SGML's (and not
> groves, which post-date SGML), then please present evidence. Otherwise
> let's leave aside the fact that XML was designed (in part) for browsers.

This isn't what I'm trying to say, though; the original question was why XML 
didn't have metadata to handle change control, stating how applications 
should deal with elements/attributes they don't recognise. And my point is 
that while the PNG group had seen this problem arise in things like TIFF and 
decided to guard against it, the XML group were thinking much more along the 
lines of "We publish DTD; everyone uses DTD; we only publish new DTD when we 
feel people won't mind upheaval and reprogramming". The PNG format is 
designed to deal with different versions of everything interoperating as best 
as they can. While I've seen XML and SGML vocabularies that uses a different 
DTD identifier for different versions to keep the versions from ever mixing!

> > But for tables, it's clunky because you're having lots of nodes with the
> > same structure under a parent node. Repeating that structure gets
> > laborious to type if you're a human and is laborious to process if you're
> > a computer. For a table of tuples, it's much easier for all parties to
> > deal with:
> >
> > email,name
> > alaric@alaric-snell.com,Alaric Snell
> > paul@prescod.net,Paul Prescod
> > foo@bar.com,"Comma Containing, Mrs"

> No, actually, I don't see it as being easier for a computer to keep a
> stateful mapping of columns to column titles.

Storing the list of column titles from the first line being easier than what, 
the state management of an XML parser?

> And although the
> compressed form is more convenient for a TYPIST, it is actually much
> easier to read the XML spelling out the attribute names. If you are
> adding only one entry (as opposed to typing thousands), I also prefer
> the XML because you can't forget whether the "0" is the UID or the GID
> (to use an /etc/passwd example).

/etc/passwd doesn't *have* column headings though, it's a bad non-extensible 
non-flexible format :-)

> > ...and of course for graphs you need a system of primary keys and
> > pointers like id= - and you have to build your graph over a hierarchy
> > which isn't always optimal; at worst you use the hierarchy to build a
> > list of key-value pairs, then use the list of key-value pairs with
> > 'reference' nodes in the values to build a graph :-/
> At worst it isn't much worse than any other serialization of a graph.
> Reading serialized graphs is always a pain.

It's quite nice with the s-expr notation for it, though. See below.

> > Or how about a multiple-parent hierarchy, hmm? A family tree?
> >
> > Not so bad in CSV:
> >
> > name,mother,father
> > Alaric Snell,Karin Owens,Lionel Snell
> > Karin Owens,Jean Byrne,James Owens
> > Lionel Snell,moment of shame as I forget my grandparent's names...
> > ...
> <person name="Alaric Snell" mother="Karin Owens" father="Lionel Snell"/>
> <person name="Karin Owens" mother="Jean Byrne" father="James Owens"/>
> ...
> It isn't as if CSV handles this issue naturally and the XML is massively
> complex.

You're using a short fat tree to store another tree, my point was that XML's 
hierarchy is only a particularly limited kind, beyond which you need to fall 
back to the same tricks.

> > Now, of course, the counter argument is that you put up with XML being
> > clunky at tuples or graphs because it's good at hierarchies and lists and
> > bearable at tuples and graphs so you overally have something that can
> > kind of manage everything...
> Any serialization of graphs is going to be clunky (XML is no worse than
> CSV or s-expressions) and I personally have no problem with XML for tuples.

s-exprs are nicer since they EXPLICITLY express the graph structure; general 
tools can deal with the graph. With XML, there is no way to pull out the 
references other than parent/child relationships except where people have 
used xlink, which does not seem to currently be as ubiquitous as one would 

>  >...
>  > [s-expression idea]
> >
> > And kapow! I had a slight modification of s-expression syntax being my
> > text input format. For completeness, here's a plain list in s-expr:

> Yes, we discussed all of this five years ago when we were defining XML
> (and years before that, and every year since then)! If you don't mind
> having two syntaxes, sure you can do better than XML for certain kinds
> of data. You could even have three or four or five syntaxes for
> different kinds of data. But XML demonstrably hits the 80/20 point such
> that most developers think it is good enough for both data and documents.

How do you mean multiple syntaxes? I presented a single syntax that handles 
many cases neatly. My thing for embedding styling in s-expr strings was a 
grotesque hack to make it look like HTML; a more elegant shorthand could be 
had, I'm sure.

> > ...
> > Now s-expresions look pretty hierarchical here, but that's just a
> > shorthand; they're really full graphs. I can't remember the graph syntax
> > since I rarely used it but basically you can name any node with a bit of
> > attached metadata and then say "Insert a reference to node X here" where
> > you need it to create links.
> You aren't talking about s-expressions anymore. You're talking about a
> syntax you invented.

No I'm not. This is standard s-expr stuff from the Lisp days.

Here it is! Used # symbols, not @s. My bad!


...ugh, they mandate using numeric identifiers, I prefer my interpretation 
with symbols after all :-)

>  >...
> >
> > Now, if the people who came up with XML as data had wandered across a
> > nest of Lisp hackers instead of XML, might we not have seen something
> > like my s-expression variant with the symmetric tags being produced,
> > perhaps augmented by a syntax to embed nodes in text strings as I hacked
> > together with a macro system, then namespaces for symbols defined, then a
> > transformation language and a path language and so on defined?
> Sure, if S-expressions had the features you propose (they don't)

They have the graph feature, and the other two are just syntactic sugar to 
please people who don't like all the ()s.

> and a schema language.

We can *make* a schema language. I'm comparing XML with s-expressions here, 
not "The world of XML" with just s-expressions, since if so we'd include 
Scheme as our transformation and schema language, no?

> I've been through this argument too many times:
> http://www.prescod.net/xml/sexprs.html

Ok, let's take a look.

1) Starting with Syntax

Very much in the eye of the beholder :-) I prefer s-expressions, you prefer 
XML. Ok.

2) Redundancy is Good

I showed a trivial fix for this problem with my [foo[ ... ]foo] concept, 
which I've implemented with success before, and would submit to the Scheme 
standards bodies if I thought it mattered *that* much.

3) Family matters

Ahah! So you're comparing complex, limited, and inconsistent schemas, 
infosets, xpaths, xqueries, and xslt against Scheme and (whisper lest you 
waken him!) his big brother Lisp? Muhahahah!

3a) Principle of Least Power

That's missing a point - it confuses Power with Complexity, I suspect. The 
most powerful languages can be the simplest. One can write a Scheme 
interpreter with surprising ease, and the standard library that runs on top 
of it is probably about the same size as an HTML DTD... ok, not that I've 
actually seen the byte size counts of either, but I'm about as worried about 
the complexity of each. A scheme runtime is going to be similar in complexity 
to an XSLT engine, actually, and it'll be able to do more!

Put another way, power is the size of the set of things you can do with a 
tool. Clearly, this is an attribute we want to increase. However complexity 
is a metric of the cost of performing tasks (including initial learning) with 
the tool, and is to be reduced. If you assume power and complexity are 
inexorably related then indeed you need to find a happy medium, the least 
complex system that has enough power to fulfill your needs. But Turing 
completeness can be had from a mathematical system you can describe on the 
back of an envelope, and that can be used to make a more expressive schema 
notation than XSD (I'm think a graph rewriting system here in which valid XML 
documents are ones that can be rewritten to a single token, "VALID", or 
something like that).

> > Yep. I just think we could have come up with a system that provides a
> > better overall gain for humanity - and has less areas where it produces
> > small benefit. The s-expression corresponding to a CSV file is little
> > more complex than the CSV would be, so it's already less of a loss than
> > using XML in that situation.
> You're presuming that there is no cost in having multiple syntaxes:
> different ones for different domains. But clearly there is _some_ cost.

Not in this argument. I do happen to be a fan of multiple interopable 
syntaxes, but not of multiple models. I'd like my s-expression to be 
expressible in memory as pointers to cons cells, in front of me as a nest of 
brackets, and in a database as a compact bit string...

> > XML's gained a following, but the hype is waning already. It's lodged in
> > many niches but it's failed to change The Web as I see it, what it was
> > originally designed for... although XML with embedded stylesheets being
> > served over HTTP and displayed by browsers would have been a better Web
> > the improvement is justifiably marginal compared to the costs to vested
> > interests, so I'm not too surprised.
> The Web as we see it has stagnaged since Microsoft wiped out Netscape.
> But all of the most innovative emerging technologies on that front are
> XML-based: RSS, SVG, XUL, XForms. It is way too early to say that XML
> didn't change the Web. Give it five years.

It hasn't changed it yet, though, and the momentum to do so seems to be 
waning; once I kept hearing people asking "Um, should we be using XML for 
this stuff?" but now they're back to their HTML templates and (grumble) CGIs 
with code and HTML entwined.

> > Now I don't think that would be *practical* with SOAP over HTTP! My ls
> > request ran over UDP packets with sizes of 100-200 bytes - one packet to
> > request, another packet to respond, on three-way handshakes or teardown
> > and no TCP overhead wasting time reordering the response packets to make
> > them come in the order the server sent
> I guess the thousands of people using WebFolders are all hallucinating.
> ;) I would guess that there are more people using those every day than
> NFS (but not as many as SMB -- yet).

That thing's just dynamic uploading and downloading of files via HTTP, isn't 
it? When I run a program over NFS, it's fast because the file is demand paged 
over the network, it doesn't have to wait until it's downloaded the whole 
thing before it can get started! And any other file that is read 
nonsequentially or partially will be unweildy too... and I suppose these Web 
folders use HTTP to fetch directory information too (in case you hadn't 
guessed, I've not had the privelege myself) so it'll hardly be nippy to 
navigate, will it?

They might be using range requests to speed up reading, and perhaps you can 
PUT to a range in a resource and have the server understand you, but even 
then you still have no standard way to represent chmod, chown, and chgrp or 
ACL changes!

I don't think HTTP is a usable file sharing protocol. Just imagine mounting 
/var over HTTP as the mail spool for a failed-over mail cluster :-) And how 
practical is an ls -lR over these Web Folders, hmm? I suspect it's no more 
than a nice user interface for downloading and uploading files rather than 
something you'd actually want to use as a filesystem.

>  > (and I can submit requests without needing
>  > to wait for the response to the last request, which I don't
>  >  think HTTP 1.1 allows but I may be wrong).
> That's what HTTP 1.1 pipelining is.

I was wrong then; good job I put that qualifier in :-) But how does it get 
around the underlying problem in TCP? Does it open extra TCP connections to 
handle parallel requests?

> > I guess that's part of what makes my blood boil about XML data and XML
> > for interprocess communication and all that; the reinvention of wheels,
> > with less care than the first time round :-(
> If it had been done right the first time around there would be no
> temptation to do it again. It surprises me that there are still people
> who don't "get" that schemas are an important part of the difference.
> Mixed content is another important part.

Schemas are hardly new to XML. Nothing in XML is new; you can't say that this 
feature or that feature is critical. All you can say is that this 
*combination* of things is critical, these features we left out that other 
systems had are not useful because of X or would spoil the ensemble because 
of Y.

> Of course, I'm not defending SOAP and the idea of something like NFS
> running on top of SOAP running on top of HTTP makes me cringe.

I know, don't worry, I don't doubt your sanity, just your reasoning :-)

>   Paul Prescod


A city is like a large, complex, rabbit
 - ARP


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS