Re: xinclude using xpointer

[ in response to your 15-August reply to my 21-June feedback ]

> > In terms of the document, I think my preferred change would
> > be making fragment IDs in the "href" attribute be illegal, thus
> > making XInclude suitable for "low level" implementations.
>
> The WG was unwilling to give up XPointer support, as partial document
> inclusion is a major motivator for XInclude.

For one use case, which is more of a linking application,
rather than a straightforward "low level" alternative to
external entities etc.

It's a major _de_motivator for other use cases, since it
requires all the complexity of an XPath engine, and more.


> > - The content model should be defined explicitly; I'd
> >    prefer EMPTY as the requirement.
>
> We considered this as well but felt that there was little benefit in
> limiting the evolvability of XInclude in this way.

For interoperability, should (unrecognized) content be ignored,
or treated as an error?  Having that answer affects evolvability,
in that end-users are very poorly served by the products which
will (!) use different answers.  W3C specs should be better about
eliminating such underspecified characteristics, they make trouble.


> this). It is also straightforward to map locations in the XPath data
> model to the corresponding location in the Infoset.

But the infoset doesn't have "locations", it just requires that information
be available.  You're assuming random access, which is not at all
a requirement (praise be!) of the infoset.  I hope you mean "information"
(item :) there.


> Also, we recognize that XPointer support is the largest part of XPointer
> support, and will keep our eyes on this issue during the CR phase.

Yes, that's a problem a number of folk would like to see fixed.
(By removing the XPath requirement.)  You might have noticed
some xml-dev discussions on the topic.

- Dave