Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Feeling good about SML
 On Tue, 16 Nov 1999, Sean Mc Grath wrote: > I think there is a step before SML which -- if it went well -- > might even remove the need for SML: > > 1) Tie down what the bifurcation areas that cause XML > interoperability problems and allow people to throw > the phrase "XML parser" around with wild abandon. > e.g. external subset processing, external entity references, > Unicode encoding(s) supported, location information, etc. etc. > > For arguments sake, lets call this the XML Feature Manifest > (XMF). I think there's a step or two before even that. We've been talking about "simplifying" XML without sharing an operational definition of "simpler." I've seen people interpret in this discussion in at least three senses: 1) Requiring less code to parse. 2) Requiring fewer characters to be transmitted over a communication link. 3) Requiring less time and effort to learn. These senses are orthogonal; efforts that achieve one may not necessarily help with the others, and may make matters worse. I'm not convinced that 1) is even a problem, and I believe people like David M. when they say that subsetting features would not result in a substantial footprint reduction for a well-written parser. I think what we have here is really an issue of API complexity, but APIs can be simplified without touching the language itself. For example, it would be reasonable for a parser to be used in a wireless device to have very little error-reporting ability; a simple go/no-go indication would be enough. Such a parser probably doesn't need facilities for obtaining the character position of an error or the exact nature of the error; there's nothing the user of the device would be able to do with that information anyway. Therefore, such a parser wouldn't need to store code for error messages. Anybody who needed to debug the data being sent could use a bigger parser on a desktop machine. Nothing about XML itself mandates the presence of development-tool hooks in a parser API, yet the presence or absence of such hooks can make a big difference in a parser's footprint. 2) can be handled transparently to the language itself. One can either use standard general-purpose compression mechanisms, or mechanisms (like SHORTTAG encoding) that take advantage of the textual properties of the language. 3) is really a matter of simplifying APIs, not the language itself. I don't believe the cognitive load of XML according to the W3C recommendation is excessively high for a programmer who needs to write code for generic XML processing. If a programmer only needs to deal with a handful of XML applications, the solution is to create application-specific APIs for those applications. The user of such APIs shouldn't have to even be concerned with the fact that the data is going in and coming out as XML. To sum it up, before we can decide *how* to simplify XML, we need to decide *why* we need to, and *if* simplifying the language itself is the solution. Otherwise we run the risk of premature closure, constructing a problem definition based on the characteristics of the perceived solution. 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
|
|||||||||
