RE: xinclude using xpointer

> -----Original Message-----
> From: David Brownell [mailto:david-b@pacbell.net]
> Sent: Thursday, August 30, 2001 1:17 AM
> To: Jonathan Marsh
> Cc: www-xml-xinclude-comments@w3.org
> Subject: 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.

So how do we decide which is more de-motivating?  We recognize the data
point you are providing (it appears to be in the majority), but we need
more data points.  CR will provide that.

> > > - 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.

I agree!  XInclude doesn't constrain the content of the include element.
Neither does the processor allow you to do anything with it - so it must
be ignored.  My latest draft says this explicitly.
 
> > 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.

Yes.  And XPointer will indeed impose some random access requirements on
the infoset when used in XInclude (sigh).  This has already postponed
one of our prototype efforts.

> > 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.

It would be nice to have a stripped-down XPointer that was easy to
implement.  In the short-term though, the question is: is XPointer
better than nothing or not?  That's a hard question to answer, and one
that CR should provide more data on.  If XPointer implementations are
preventing XInclude implementations, we can either ditch XPointer or
ditch XInclude.  

Mostly I want to communicate that I recognize that this is a serious
problem, one that has serious ramifications.  But we are unable to take
immediate and drastic action without more data.  Thank you for providing
us with your views.

> - Dave
>

Received on Thursday, 30 August 2001 13:23:34 UTC