[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Re: I can XInclude where I bloody want to
Paul Prescod wrote: > I'm wouldn't mind it defaulting to ON for XSLT stylesheets. On the other > hand, what value does XInclude provide above and beyond xsl:include? For one, xsl:include can only occur in a certain place; it is essentially just for bringing children of the xsl:stylesheet element from one stylesheet into another. It is not a general-purpose, application-side supplement to or replacement of parsed general entity references at the parser level, as XInclude is. > I would say that you should default to doing only things > explicitly described in the XSLT and XML specifications and let people > layer on their own ordering of behaviours. First do no harm! I don't disagree, but I don't think it follows that XInclude processing before XSLT processing violates the specs. It's just like the whitespace preprocessing issue in MSXML's DOM. XInclude doesn't conflict with the XML spec; it's something that goes on at the application side, at the application's discretion. XInclude doesn't conflict with XSLT+XPath, either; XPath just says a virtual tree, intended to be a certain kind of representation of an XML document, exists and what it consists of. XSLT only covers the processing of that tree, and an XSLT processor is only required to behave as if it is acting upon such a tree. There are no rules as to how the tree is obtained. An XML document in linear character form doesn't even have to be the source of the representation; as has been pointed out before, the representation can come into existence in any number of ways, and a parser doesn't even have to be involved. I think we take a lot of things for granted about the XSLT spec, based on the implementations that have formed around it. An XSLT processor is only required to behave as if it has acted upon a certain kind of abstract structure. It really doesn't even require any input at all, as long as it always gives the right result! Of course, since we don't have mind-reading software, we have to give it some kind of input, and the implementations that have arisen do give us convenient options for input -- but this input should be considered hints to the processor to help it generate the result. > Eventually to use an XSLT processor you have to go through a > long mental checklist about what features will be applied and *how to > turn them off*. I don't see XInclude processing before XSLT processing as setting a terrible precedent. Having the option of turning it off will take care of the edge cases, and having it on by default isn't a violation of any specs or principles. If it violates assumptions that we tend to make because of how XML parsing and XSLT processing chains are traditionally set up, then perhaps there's an argument for a processor to be "nice" about it. I just keep thinking back to MSXML and whitespace, though. There's an example of a processor bucking the trend, and on the whole, no one is really suffering because of it. I think the reason for this is that most people pick an XSLT processor, code to its quirks, its features and its APIs, and they stick with it. Your nightmare scenario is here today. It's a pie-in-the-sky idea to think that XSLT processors are completely generic and interchangeable, and that XSLT code can always be written to work identically on any XSLT processor. Anyone who has dealt with processors having different ideas about relative URI resolution, or anyone who has built an application on JAXP and then tried switching processors from Saxon to Xalan* (or vice-versa, or in an environment with multiple processors in the classpath), can probably attest to this. We're just not there yet, and I don't think that it's a high priority. - Mike ____________________________________________________________________________ mike j. brown | xml/xslt: http://skew.org/xml/ denver/boulder, colorado, usa | resume: http://skew.org/~mike/resume/ * maybe this situation has improved since the last time I tried it
|
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
|