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

Re: Re: I can XInclude where I [expletive deleted] wantto

• To: David Carlisle <davidc@n...>
• Subject: Re: Re: I can XInclude where I [expletive deleted] wantto
• From: Elliotte Rusty Harold <elharo@m...>
• Date: Wed, 1 May 2002 11:29:20 -0400
• Cc: xml-dev@l...
• In-reply-to: <200205011510.QAA06067@p...>
• References: <000601c1f064$3acd3f50$6501a8c0@pcukmka><3CCEDA7F.D824147D@f...> <p04330101b8f59f616cee@[192.168.254.4]><200205011510.QAA06067@p...>

At 4:10 PM +0100 5/1/02, David Carlisle wrote:


>The problem with outlawing this is that in may cases (almost all cases
>for MSXSL) there is no direct link bewteen the source tree for XSLT and
>any literal linear XML file or string.
>

I'm not familiar with the detailed API for MSXSL 3.0. For Java, where 
I am familiar, it is possible to pass an XSLT processor a URL 
pointing to the actual document or a stream from which the document 
is read. In so doing, I indicate that I want the XSLT processor to 
operate on *that document*, not some different document produced by 
performing arbitrary operations on the original document. I did find 
the documentation for what I think is MSXML 4.0 on MSDN, and that 
version at least has a method that takes the string forms of URLs as 
arguments for the transform method as well as methods that take DOM 
Documents.

I can also feed the processor a DOM or JDOM Document object. If I do 
that, then I am indicating that I want the processor to transform 
that DOM or JDOM Document object, and I don't really care whether 
that Document was read from a file or stream or not. If it was 
modified in memory, then I modified it. The XSLT processor may not be 
transforming the original document, but it is still transforming the 
document I tell it to transform. I just don't think it's acceptable 
to give a processor document A and have the processor decide, "I 
don't like Document A. I'm going to transform Document B instead."


>I think that if you want to ban automatic xinclude processing the you
>need to constrain XML parsers not XSLT engines. Conceptually The XSLT
>engine will just ask for the parser to give it back a tree. If the
>parser has expanded xinclude and removed white space, then the XSLT
>engine can't do much abut it.
>

Constraints on the parser already exist.The XML spec defines what 
information a parser must supply to a client app. The DOM spec 
defines how white space is handled by DOM. The SAX spec defines how 
white space is handled by SAX. Fortunately nobody I'm aware of is 
really arguing about these.
-- 

+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo@m... | Writer/Programmer |
+-----------------------+------------------------+-------------------+
|          The XML Bible, 2nd Edition (Hungry Minds, 2001)           |
|             http://www.cafeconleche.org/books/bible2/              |
|   http://www.amazon.com/exec/obidos/ISBN=0764547607/cafeaulaitA/   |
+----------------------------------+---------------------------------+
|  Read Cafe au Lait for Java News:  http://www.cafeaulait.org/      |
|  Read Cafe con Leche for XML News: http://www.cafeconleche.org/    |
+----------------------------------+---------------------------------+

• Follow-Ups:
  • Re: Re: I can XInclude where I [expletive deleted] wantto
    • From: David Carlisle <davidc@n...>

• References:
  • Re: I can XInclude where I [expletive deleted] want to
    • From: Elliotte Rusty Harold <elharo@m...>
  • Re: Re: I can XInclude where I [expletive deleted] want to
    • From: David Carlisle <davidc@n...>

• Prev by Date: RE: Normalizing XML [was: XML information modeling best practices]
• Next by Date: RE: SOAP and the Web
• Previous by thread: Re: Re: I can XInclude where I [expletive deleted] want to
• Next by thread: Re: Re: I can XInclude where I [expletive deleted] wantto
• Index(es):
  • Date
  • Thread