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:11 AM +0100 3/4/02, Eric van der Vlist wrote:

>But this is also the case with external parsed entities since a non 
>validating parser may not parse them. And beside this case, I 
>strongly feel that any reference to any document introduces 
>unpredictability, especially when it's over the internet and 
>especially when there is no fallback mechanism.

You cannot a use a parser that does not resolve external entity 
references for XPath and XPath based applications. Given that all 
XPath sufficient parsers do resolve external entity references, 
canonicalization either succeeds completely or fail completely. There 
is no middle ground. XInclude has a middle ground, quite a lot of 
them in fact. That's what makes it unpredictable.

>Why not? If I parse a XML 1.0 document with a non validating parser 
>which doesn't parse external entities and if the result is still 
>conform to namespace in XML I don't see why a XPath data model 
>couldn't be built. It might not be significant but it would still be 
>a XPath data model...

The result won't be conformant to XPath except in the uninteresting 
case where the document doesn't contain any external entity 
references. The XPath data model does not include any representation 
of unexpanded entity references (or any other kind for that matter).

>It happens that XPath specifies that those external entities need to 
>be expanded and you are (of course) right, but I do think that this 
>is historical too.

No, it's not. It was a deliberate decision by the XSL Working Group 
and the XML Linking Working Group. XPath followed XML by almost two 
years, and the groups had full knowledge of what they were doing. 
They chose to make XPath require resolution of external entity 

>OTH, what's the use of XInclude if it cannot become core and 
>transparent for the applications. We already have XLink to indicate 
>"soft inclusions" and I don't see any use for XInclude if it doesn't 
>become a hard (or core) inclusion like external parsed entities.

But XLink *doesn't* indicate soft inclusions. It did at one point in 
time, but that was ruled out of scope and moved into XInclude a 
couple of years ago. There is no standard way in XLink to indicate 
that resource should be merged into the result document's infoset. 
You can indicate that a document can be graphically embedded (like an 
IMG link in HTML) but that's a very different thing. It does not 
affect the result document's infoset. XInclude does.

The fact is XInclude is not what you want it to be and does not do 
what you want it to do. What you want would probably require breaking 
the definition of XML 1.0. You want to redefine what an element means 
and how it is treated by all processes, provided that the element's 
name is xinclude:include. That doesn't seem likely to happen.

| 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