Subject: RE: Re: [xsl] XInclude From: Salvatore Mangano <smangano@xxxxxxxxxx> Date: Sun, 2 Jun 2002 11:27:11 -0400 |
> XSLT is a component that transforms input trees to create result trees. > XInclude is another component that transforms input trees to create > result trees. The question of how such components are assembled into an > application is the subject of XML Pipeline. XSLT itself should not > attempt to define the processing pipeline. Yes, I see your point. However, XSLT being a language for transforming tree's, as a practical matter, processors also provide a method for serializing those trees. It is nice to have language and tool definitions that are pure, but at the end of the day, standards must solve practical problems and allow developers to work in an environment where things work in an intuitive fashion across many implementations. As a practical matter in organizing XML data, it is nice to have a language neutral facility such as XInclude for breaking large documents into separate files. XInclude seems like a simple way to do this and I believe that was the motivation for creating it. Now, once we have something simple like XInclude it would also be nice if SAX parsers, XSLT processors and XQuery processors contained options to either treat an XInclude element just like any other element or recognize it as a special element and process it in the appropriate way. Just because standards X and Y are independent standards does not mean there should not be some W3C endorsed recommendations about how the standards should interact. (Climbing onto my soap box) It seems to me (as an outsider) that the W3C is not in touch with the realities of developing software in the real world. They are just happy to sit and create standard after standard that address one piece of the puzzle and not how all the pieces fit together. When you leave it to vendors to address these type of user needs then you leave the poor end user locked in to specific implementations. A case in point, was the "bone headed" decision in XSLT 1.0 regarding the difference between node-sets and result tree fragments. The decision was based on some purists idea of what XSLT should be used for and not what people actual need to do. Thus, a whole bunch of implementers were forced to thumb their nose at the standard an implement a node-set function. Of course, each node-set function in each processor was accessed and even named differently creating a nightmare for us poor schmucks <sp?> trying to create portable stylesheets. (Climbing off my soap box) XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] XSLT+XPATH as SVG scripti, Max Froumentin | Thread | RE: Re: [xsl] XInclude, Michael Kay |
Re: [xsl] XSLT+XPATH as SVG scripti, Max Froumentin | Date | RE: Re: [xsl] XInclude, Michael Kay |
Month |