Re: Feeler for SML (Simple Markup Language)
Michael Champion wrote: > 1 - I'd like to see an activity not unlike the one that defined SAX a couple > of years ago collaboratively researching what a minimal subset of XML and/or > the DOM for high-performance and/or small footprint processors might look > like. This would entail some actual code experiments to see if there really > is a significant decrease in processing time or code footprint by throwing > out support for these features. If there's no empirically demonstratable > gain, I for one don't want to continue the pain of this discussion. I guess there's no harm in looking into this, but this seems like a road to nowhere to me. On the one hand, it implies a serious risk of unnecessary confusion because the differences between XML and the putative SML will be too subtle for non-XML freaks to grog. On the other hand, any compromise that is found is going to lead to inevitable satisfaction, with some people feeling that too much was eliminated while others feel that too much was left in. > 2 - Assuming for the moment that a gain can be demonstrated, I'd like to see > a mechanism in XML itself to allow XML messages, documents, etc. to specify > that they use only some defined subset of features. In other words, I'd like > to see some built-in mechanism for "bifurcating" XML without descending into > the chaos of non-interoperability. This is starting to sound like a pretty good idea. I imagine something like the SGML declaration but specific to a given schema, rather than a specific instance. This would enable a schema developer to say, for example, that PIs, external parsed entities (or my preferences, any entities), attributes, etc. are not usable with the schema in question. This is something that the schema WG could add to the current spec with very little effort. Simon posted something about having done some work in this direction, but I can't connect to his site right now. In any case, I'll happily write a short proposal if no one else wants to; it should only be about an hour's work. > 3 - I'd like to see some specification or demonstration for how an XML > processor that is optimized for a subset of the spec can "barf" on external > entities or other unsupported features in a way that would allow it to > potentially extract useful information out of the document or message it's > processing. For example, I might (for some reasons of my own) document or > "decorate" an XML message with attributes or entities, but when Don Park > gets it ;~) , his stripped down processor should be able to extract the > "wheat" (simple element values) and ignore the "chaff" (my documentation and > decoration). Such a mechanism would have to be much lighter weight than what > would be possible with DTDs or schemas. > (Again, if it can be demonstrated that something functionally equivalent can > be done *efficiently* without mucking with the XML spec, so much the > better). And alternative that is certainly worth considering: the processor simply rejects the document if an unsupported feature is used. Since the document authors are presumable writing (or the software developers generating) an XML instance on the basis of a schema, the onus should be on them to respect *all* aspects of the schema definition, including supported features. The best thing a processing app can do is reject the document out of hand, letting authors know that their implementation is faulty and forcing them to fix it immediately before non-conformant documents are unleased to wreck havoc. Your approach runs the risk of producing behavior that was not expected and might therefore have undesirable side-effects (considering the implications for e-commerce, among other things). Matthew 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...)
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format