[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: ANN: xpath1() scheme for XPointer

martin soukup
At 9:50 PM -0500 10/27/02, Martin Soukup wrote:

>Although a forced coupling seems wrong to me also, are you saying you
>believe there is something wrong with an optional coupling? I think that
>mixing Xpath analysis with the parse phase is essential to some
>applications of XML. Namely when performance is essential.

I'm not sure I quite understand where you're coming from. I may agree 
with you. I may not. I'm completely comfortable with the user asking 
the parser to do XInclude resolution, and then having the parser do 
it, or, for that matter, do other much more complex things the user 
requests. In this case, the user knows what they're transforming, and 
knows that they're applying their stylesheet to the post-processed 
document, not to the original document. That's all fine and seems 
like a very good process. The local client is in control.

What bothers me is when parser vendors (or XSLT processor 
implementers) add this as the default behavior without a user request 
for it. For example, consider this template rule:

<xsl:template match="xi:include">
    <p>Load content from <a href="{@href}">here</a></p>

If I apply such a stylesheet to an XML document that contains some 
xi:include elements, then I expect it will give me the results I have 
requested according to the clear algorithm defined in the XSLT 
specification. In this case, that means changing each xi:include 
element into an HTML paragraph with a link. Doing otherwise because 
the stylesheet engine has taken it upon itself to expand XIncludes is 
a bug.

The whole point of XSLT is that the user gives the engine a document 
and a stylesheet, and the engine transforms that document according 
to the instructions in the stylesheet. It should not insert its own 
additional instructions. It should not do transformations other than 
what the user has requested via the style sheet.

Now if the user first passes the original document to an XInclude 
resolver, and then gives the result of that process to the stylesheet 
engine, the stylesheet engine will naturally operate on the 
post-include document. For performance's sake, as you note, the 
inclusion may be merged with the parsing, rather than being a 
separate process. However, it should still be done only at user 
option. Otherwise, there is a whole class of documents and style 
sheets that the stylesheet engine does not correctly process.

| Elliotte Rusty Harold | elharo@m... | Writer/Programmer |
|          XML in a  Nutshell, 2nd Edition (O'Reilly, 2002)          |
|              http://www.cafeconleche.org/books/xian2/              |
|  http://www.amazon.com/exec/obidos/ISBN%3D0596002920/cafeaulaitA/  |
|  Read Cafe au Lait for Java News:  http://www.cafeaulait.org/      |
|  Read Cafe con Leche for XML News: http://www.cafeconleche.org/    |


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.

Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.