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 ]

Elliotte Rusty Harold wrote:
>>Elliotte Rusty Harold wrote:
>>But isn't this difference more historical than technical?
> No, it's completely technical, not at all historical. Entities don't 
> have a fallback mechanism. XInclude does. It's irrelevant which one 
> was defined first. The fallback mechanism makes canonicalization an 
> unpredictable operation on the post-include infoset, which is exactly 
> what canonicalization is trying to avoid.

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.

>>If you build an application on XInclude, you will want this inclusion
>>to be as transparent as possible and the document before XInclude 
>>may be meaningless, as meaningless as a XML document without its 
>>external parsed entities. In both case, you can generate *a* XPath 
>>data model and this data model is not appropriate in either case and 
>>is not *the* XPath data model of the merged document.
> That's not true.  You most certainly can build an XPath data model 
> for an unmerged document that  has some xinclude:include elements. 
> You cannot build such a data model for a document in which the 
> external entities are not resolved. 

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 

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.

> The XPath data model only applies 
> to documents in which all external entities are resolved. So the two 
> cases are *not* the same. Furthermore, both unmerged documents do 
> have meaning. Theya re not meaningless. For instance, imagine a book 
> in which the individual chapters are referenced by either XInclude or 
> external entities. Even without resolving those entities this 
> document may contain useful information, such as the table of 
> contents.

Exactly, both are useful (and it's a reason why I have always said that 
something of the xs:include semantic should be preserved after the 
merge) but they're not the same infoset. What you're saying here 
comforts by belief that XML 1.0 (and XPath) are broken when they purely 
and simply replace the entity references by their values and forget that 
they were entity references.

> A lot of the confusion comes from wanting to treat xinclude:include 
> elements as some magical thing that does not satisfy all the usual 
> rules of XML processing, but that isn't true. An xinclude:include 
> element is just like any other XML element which some processes may 
> choose to impart certain semantics to. Most likely, these semantics 
> will result in the production of a new and different document, but 
> they don't have to; and in some cases they won't.

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.

See you in Seattle.
Eric van der Vlist       http://xmlfr.org            http://dyomedea.com
http://xsltunit.org      http://4xt.org           http://examplotron.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