Cart
[Home] [By Thread] [By Date] [Recent Entries]
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@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To unsubscribe, mailto:majordomo@i... the following message; unsubscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
|
