This is the mail archive of the xsl-list@mulberrytech.com mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: Re: XInclude


> 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]