Status of SML?

[Clark C. Evans]

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.

;) clark

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;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)