Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: How to spell "No PSVI" in XSLT 2.0 ?
 Arjun Ray wrote: > The distaste for DTDs seems to be a politically correct kneejerk reaction. > Quite apart from real and imagined flaws in their information content, I > sense a prejudice that processing DTDs is inherently "difficult" (and thus > something it might be useful to, um, "optimize away".) Whether it is difficult or not, it takes processing time and other ressources. If you have a throughput of several hundred SOAP requests per second, you'll be glad to optimize away everything that could be optimized away, in particular if you have to do some stuff a validator does but even more thorough, like checking that your DB key isn't only there but also fits your format restrictions, and if you know that some validation tests have to be checked for but are actually never triggered. In fact, really high performance web services toolkits don't even use general purpose parsers, they compile customized parsers from the service descriptions. Another interesting case are XML pipelines, for example plumbing a FO processor to an XSLT processor (rather common), or Cocoon's pipelines. DTDs don't fit in there well, at least as long it is universally assumed that validation is an integral part of the XML parser. > you may find considerable sympathy if you bash parameter entities, but > only for the right reasons.] That's interesting. How do you write large, complex DTDs without parameter entities and keep them maintainable? Disclaimer: this doesn't mean I like parameter entities. XSchema has types for the purposes I have to use parameter entities in DTDs. More disclaimer: I don't like XSchema very well either, but it solves some problems I had with DTDs. > 1. No entity references. Good! Should be enacted immediately! (with some amendments regarding character references) > While at it, the 5 predefined ones should be abolished too. IOW, poof the > syntactic device altogether. As far as the XML world is concerned, I > don't think this is a loss (until, of course, the device gets reinvented, > which, again of course, it will - but hey, it won't be NIH, it'll be new > New NEW!, and so it'll be k00l - see XInclude for the shape of things to > come.) XInclude is not the same as an entity reference http://www.w3.org/TR/xinclude/#rel-extent And it fits into a DTD-less world, of course :-) From an XSLT perspective, XInclude is much better than entities. Sometimes you don't want to have the references expanded, either because you want to process them yourself, or because you want to pass them downstream. With XInclude, and supposed you can tell the upstream XML processor (the parser) to leave the XIncludes alone, the XSLT processor sees just another XML element, and it can be processed like any other. In case of entities, you face some difficulties, because there are not "entity nodes" or something in the (logical) XML data model. XPath and XSLT would have to be extended to cope with this, and the XQuery people would probably find "entity nodes" annoying. > 2. No data content notations. > > Again no loss: the average XML wonk would know know a notation if one bit > him. Must be some old-fogey SGML weirdness, poof it. The rest of the WWW uses MIME types. Why forcing everybody to declare their content types itself, possibly in an incompatible way? > 3. No default values for attributes. > > This isn't so bad. Goal 10 of the XML spec institutionalizes verbosity, > in which can be included routine denormalization of everything in sight > (if something needs repeating everywhere, then repeat it everywhere - if > that bothers you, then write a program to do it for you.) Hmm. XSLFO seems to have defaults for their properties (which are syntactically expressed as attributes). Interestingly, I've never heard someone complaining that there should be a FO DTD with the proper defaults coded in (which is impossible to do for all cases anyway, because of some rather quirky dependencies). And nobody writes *every* possible attribute to a FO document, rather they seem to rely on the defaults built into the FO processor. Same for the SOAP/webservices world: the application takes care of it. > 4. No ID declared value. > > With the probable exception of entity references (see #1 above) this was, > AFAIR, the main reason to require that even non-validating parsers process > the internal subset - SGML syntax didn't have a purely syntactic means to > identify the ID attribute, and XML 1.0 wasn't about to invent one (though > it could have.) > > Losing IDs may have implications for XPointer, but since there's no way > now to identify IDREF attributes either, this too is no loss. When I started with XML I thought IDs are great. Some years later and with routine processes involving merging and splitting XML documents, IDs have lost their appeal. I need names which are unique over a *set* of documents. IDs are not sufficient for this. And XSLT has xsl:key/key(), which is much more versatile than ID/id() anyway. Nobody in the XSLT community would be hurt if IDs are dropped, many wouldn't even notice. This doesn't mean that xsl:key doesn't have deficiencies. Also, I regret that XSLT and XSchema have slightly different views on what's a key and what it's good for. But then, life has always been difficult... > So, the news is uniformly good for implementors. Go for it! Yes! Yes! YES! :-) J.Pietschmann 
|
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
|
|||||||||
