- From: Daniel Veillard <daniel@veillard.com>
- Date: Tue, 27 Jan 2004 12:02:45 +0100
- To: Elliotte Rusty Harold <elharo@metalab.unc.edu>
- Cc: www-xml-xinclude-comments@w3.org
On Mon, Jan 26, 2004 at 11:35:39AM -0500, Elliotte Rusty Harold wrote: > > This has been brought up before, but a recent test case raised by > Jonathan Marsh indicated that the problem was worse than I had > thought. An XPointer without an href part can point iunto the same > document. For exxample, > > <root> > <element id="bar"/> > <xi:include xpointer="bar"/> > </root> > > Since XPointers can point forwards and backwards this means that even > a minimally conforming implementation has to keep the entire document > in memory until it has been completely processed. Furthermore, even a > tree-based implementation can't modify a document in place because it > may need to resolve XPointers that refer to the original, unmodified > document. > > As an implemennter, I see no plausible way to handle XPointers in > SAX, and even in tree-based APIs like XOM (and presumably other > tree-based APIs) it's very tough. XPointers are an implementation > dependance conformance issue to start with because some > implementations support the xpointer scheme, some don't, and some > support it partially. However, a lot of use cases don't require > XPointers at all. I wonder if it would be better if they were > removed completely? A *lot* of my users are using and depending heavilly on XPointer, removing this would render the spec far less useful, especially since XInclude can only process well-formed document for XML inclusion, to it becomes impossible to include more than one top element. At least that constaint doesn't exist for external parsed entities, this would IMHO make XInclude less powerful than entities and render the spec nearly useless... Yes sometime having useful spec means it's harder on the implementors, I feel the pain too, but what's the use of easy code nobody expects to run ? Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ |
Received on Tuesday, 27 January 2004 18:12:11 UTC