[
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
model...
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.
<more-interesting-development-snipped/>
> 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.
Eric--
See you in Seattle.
http://knowledgetechnologies.net/
------------------------------------------------------------------------
Eric van der Vlist http://xmlfr.org http://dyomedea.com
http://xsltunit.org http://4xt.org http://examplotron.org
------------------------------------------------------------------------
|
