- From: Daniel Veillard <daniel@veillard.com>
- Date: Wed, 29 May 2002 14:48:28 +0200
- To: www-xml-xinclude-comments@w3.org
First I would like to report that libxml2 implementation is mostly complete and I got feedback it was used for documentation maintainance (DocBook based). The main interest was that contrary to entities it was possible to keep the included parts valid document instances. I think I got only one feedback from users reporting the use of XPointer expressions, they were actually xpath expression using the xpointer() scheme to select subset of the included document. I personally would prefer to keep the dependancy on the full XPointer spec but I can hardly justify it with existing use. It is clear that it makes the implementation more complex, I don't believe that the XInclude spec should itself define a subset, if such a need exist it is likely to be defined directly at the fragment identifier definition level for XML resources. There is a clear distinction too between the complexity of just implementing bare name identifier (pointing to the ID) which is an expected feature of such a fragment identifier and the full XPointer selection capabilities, I tend to think that if a level can be drawn in XInclude XPointer support it's the most natural place to make the cut. Libxml2 recent versions implement ID/IDREF fixups, this was actually asked by one user of the XInclude support. Concerning Namespace Fixup, it seems more reasonable to do that fixup when the resulting document is to be serialized back (if needed) after XInclude processing, this follows the guidelines of XSLT processing and allow implementors to keep the specificities of their namespace node implementation (libxml2 does not represent them in the document tree). Basically I think XInclude should proceed to Proposed Recommendation status with minimal changes, Daniel -- Daniel Veillard | Red Hat Network http://redhat.com/products/network/ veillard@redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Received on Wednesday, 29 May 2002 08:49:16 UTC