Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: ANN: xpath1() scheme for XPointer
> 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.
Yes, I agree with that. That's exactly where I was getting to. If you
want to do filters or transformations you can do them post-parse, but
within the parsing engine to gain speed. I absolutely believe that the
option should be up to the user. Automation is only good when the
automated component knows the process better than the user, and this
won't be the case for any parser.
I think I agree with the below. From my understanding, XIncludes should
be expanded and not processed?
Martin.
> 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@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/ |
> +----------------------------------+---------------------------------+
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
