- From: Jonathan Marsh <jmarsh@microsoft.com>
- Date: Tue, 8 Aug 2000 10:04:44 -0700
- To: "'d96-mst@d.kth.se'" <d96-mst@d.kth.se>, www-xml-xinclude-comments@w3.org
> -----Original Message----- > From: d96-mst@d.kth.se [mailto:d96-mst@d.kth.se] > In the second paragraph in section 3, it says external entities with > multiple top-level elements cannot be included from. Why not? It seems > to be that such inclusion can be useful. The Infoset specification does not define an infoset for external entities as standalone objects. Thus we can't transform to or from them. The WG discussed whether it would be useful to define an infoset for this case, and decided not to. My view on this (which may differ from the entire group's) is that: - External entity documents are not designed to be parsed separately. Many implementations will have trouble parsing an external entity document out of the context of an XML document. - Since XInclude supports XPointer, there is no need to have external files that are not well-formed. We should in the long run discourage having two types of first class XML-type documents. - There is a workaround even for documents not under your control - you can create a wrapper document and include parts or all of that. > About the issue XInclude-31-which-namespace. It seems like a good idea > to use the "xml" namespace, however an inclusion instruction like > > <someelement xml:href="foo.xml"/> > > looks a bit strange and doesn't suggest that it's an inclusion. > However, if you revert to the element syntax, then > > <xml:include href="foo.xml"/> > > would be very clear. Thanks for your input. We are clearly leaning back towards a return to element syntax.
Received on Tuesday, 8 August 2000 13:05:38 UTC