OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   RE: [xml-dev] ANN: xpath1() scheme for XPointer

[ Lists Home | Date Index | Thread Index ]

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>
</xsl:template>

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@metalab.unc.edu | 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/    |
+----------------------------------+---------------------------------+




 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS