This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
RE: Re: XInclude
- From: Salvatore Mangano <smangano at ureach dot com>
- To: "Michael Kay" <xsl-list at lists dot mulberrytech dot com>
- Date: Sun, 2 Jun 2002 11:27:11 -0400
- Subject: RE: Re: [xsl] XInclude
- Reply-to: xsl-list at lists dot mulberrytech dot com
> 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