Status of SML?
Clark C. Evans
clark.evans at manhattanproject.com
Thu Dec 16 08:05:56 GMT 1999
On Thu, 16 Dec 1999, Rick Jelliffe wrote:
> >please tell me this is just a cruel, cruel little prank james...
> >let us go on with our overburdeoned, attribute-laden lives.....:-|
> But some of the SMLies want more attributes not less: i.e., "YML"!
> YML is interesting: if attributes v. elements can be justified because
> they both are used differently in many programs (i.e., pull v. push),
> why not have a syntax that allows heirarchical attributes: the API
> provides these-new attributes in a tree and elements in a stream:
> a self-pruning tree.
I *love* this description of it. Cool. It's a fun experiment,
I think it might bear fruit, but the proof will be in the puddin.
> (Of course, the trouble with this idea is that
> prunability is more a processing issue rather than a data issues.
> And it could be done in XML by adding an attribute to elements
> or element type declarations, such as yml:prunable="yes".)
> (there is no need for a PI, since it follows element boundaries).
Certainly! However... the only tangeable meaning I
can acertain for a given grammer is defined by an
actor's resulting behavior over the language generated.
So, in a certain sense, the "processing issues" and the
"syntax" are one and the same ... In the YML case, the
clarity of the syntax allows for a clear insight into
the analogous "pruning" processing phenonomena -- which
seems to me far less tangeable.
Once this processing style is examined and understood
well, then the syntax used to bootstrap the understanding
isn't all that important anymore -- XML might do just fine.
As you point out, there are other equivalent ways to draw
the recursive binary distinction; either as an attribute,
or, perhaps defined by a pre-compiled version of an XSL
spreadsheet over a class of XML documents...
For now, there is a slowly developing thread discussing
this resulting processing model and how it could be
used to unify sequential vs random accessors (DOM&SAX).
Anyway, if you are interested, I'd love comments.
Also, this attempt at unification is one of the reasons
why I'd like to see SAX2 to become a bit more "DOM2
friendly" _only_ when it doesn't hinder the underlying
need for pure sequential access to a XML data source.
XML is still *young* and 99.99% of programs using it
have yet to be imagined... so, to Dave Megginson (whom
I have great respect), I'd like to see a more "low level"
review of SAX... to put it in-line with DOM. I feel any
pain up front will more than pay for itself down stream.
Actually, I like AttributeList far better than NamedNodeMap,
so I think DOM should do the changing, but we all know
what kind of chance that snowball has.
> XML.COM asked me to write an article on SML: it is now up in
> the current issue www.xml.com
Yes, I read it this evening. I really liked it.
> I hope it is more conciliatory. During the XML development,
> many people who were antagonistic to SGML got a grudging
> respect for it, and many SGML people who doubted toy languages
> would work shifted their positions too. I expect the same thing
> can happen with SML: it may go in an unexpected direction.
At the very worst, we will learn as a community from
the process of both stripping down XML to its minimilistic
form, and from re-introducing back XML extensions that have
clearly defined use-cases.
P.S. I'm going to have to drop out for a few days to get
a product out the door.... so if I'm curiously silent, you
know why -- I have yet to earn January's rent.
xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo at ic.ac.uk the following message;
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)
More information about the Xml-dev