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] canonicalization

[ Lists Home | Date Index | Thread Index ]

At 11:07 AM -0500 3/4/02, Simon St.Laurent wrote:

>Its lack of a clear processing model (when do these things get processed
>and what is there relation to other W3C specs) and its content-polluting
>fallback suggest some serious potential for chaos.

But there is a very clear processing model. It only becomes unclear 
when you read things into the specs that just aren't there. An 
xinclude:include element is an element. It is treated like any other 
element, nothing more, nothing less.

Like all other elements various processes may choose to treat this 
element in a certain way. For instance, a stylesheet might color it 
blue. An XSLT transform might copy it intact while changing other 
elements. A DTD might say it's an empty element. A schema might say 
it has type xsd:string. A SAX program might  log the URLs found in 
xinclude:include href attributes to a database. And there are about a 
thousand other things that can happen. But it's still just an element.

One thing a process that operates on well-formed XML documents that 
have xinclude:include elements might do is replace those elements 
with the content of the documents they point to. Doing this creates a 
new and different document, which other processes may then operate 
on. This is similar in concept to XSL transformation or XML 
encryption. An operation is performed on an XML document which 
produces a new and different XML document. The document that comes 
out of transformation or encryption is not the same document that 
went in. The document that comes out of inclusion is also not the 
same document that went in.

There shouldn't be any confusion here. At each step of the process 
there is a well-formed XML document. The W3C specs are well-written 
and clear. They define exactly what happens when canonicalization, 
XSL transformation, encryption, and various other operations are 
applied to an XML document. They  do not define in what order these 
operations have to be applied because it's not necessary. Not all the 
operations have to be performed all the time. Not everyone will want 
to perform them in the same order.

>Adding this to core of XML, as some have suggested for an XML 2.0, seems
>like a good way to ensure that developers are as mystified by missing
>content in XML 2.0 (per XInclude) as they were in XML 1.0 (per NV
>parsers and external entities).  If anything, XInclude seems likely to
>afflict a lot more of these kinds of problems.

I don't remember hearing those suggestions, and I'd certainly oppose 
them. I don't think an XML 2.0 that's in any way incompatible with 
XML 1.0 is a good idea. Even if it were, I don't think inclusion 
should be part of it. Layering functionality is a good thing.

| Elliotte Rusty Harold | elharo@metalab.unc.edu | 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/    |


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

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