RE: Multiple root inclusions

We resolved this issue as I suggested earlier, by moving section 4.2.2
to 4.5, so the prohibition would apply to any situation where an include
attempted to put content at the root that is disallowed by XML.

If you do not agree with this resolution, please let us know.  If we
don't hear from you by Jan 20th, we'll assume that you are satisfied
with this resolution.

> -----Original Message-----
> From: Jonathan Marsh [mailto:jmarsh@microsoft.com]
> Sent: Tuesday, October 08, 2002 11:49 AM
> To: Elliotte Rusty Harold; www-xml-xinclude-comments@w3.org
> Subject: RE: Multiple root inclusions
> 
> 
> 
> 
> > -----Original Message-----
> > From: Elliotte Rusty Harold [mailto:elharo@metalab.unc.edu]
> > Sent: Tuesday, October 08, 2002 4:26 AM
> > To: www-xml-xinclude-comments@w3.org
> > Subject: Multiple root inclusions
> >
> >
> > Consider the following documents:
> >
> > <?xml version="1.0"?>
> > <xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
> >    href="http://www.w3.org/TR/#xpointer(//p)" />
> 
> See 4.2.2 Multiple Nodes
> 
>  "If the document (top-level) element in the source infoset is an
> xi:include
>   element, it is a fatal error to attempt to replace it with something
> other
>   than a list of zero or more comments, zero or more processing
>   instructions, and one element."
> 
> > <?xml version="1.0"?>
> > <xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
> >    parse="text" href="http://www.example.com/" />
> 
> You're right, this behavior is undefined.  Moving the restriction
above
> from Section 4.2.2 to Section 4.5 would fix this, so it applies to all
> cases, not just when parse="xml".
> 
> > <?xml version="1.0"?>
> > <xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
> >    parse="text" href="http://www.example.com/">
> >    <xi:fallback>
> >      <p>element 1</p>
> >      <p>element 2</p>
> >    </xi:fallback>
> > </xi:include>
> 
> Likewise.
> 
> > All three seem to result in a document with multiple roots, or
> > perhaps a document fragment in DOM terms rather than a full
document.
> > Such a thing does not have an infoset according to section 2.1 of
the
> > Infoset spec which states, "There is exactly one document
information
> > item in the information set, " and then goes to state that each
> > document information item has exactly one element in its children
> > property. Thus this is a qualitatively different issue than an
> > unserializable synthetic infoset. A rootless or multirooted document
> > is not legal as an infoset.
> >
> > The XInclude processing model does not address this point. That is,
> > it does not say what happens when the processing model results in an
> > illegal infoset.
> >
> > I suspect the attempt to create such a thing should be a fatal
error.
> 
> This was our intention.
> 
> > However, whatever the specific error (or even non-error) is chosen
> > here, this possibility should be explicitly addressed in the spec.
> > Users and implementers should not have to infer the meanings of
these
> > documents by piecing together implications in other specs.
> 
> Agreed!  It was just an oversight.
> 
> > --
> >
> >
+-----------------------+------------------------+-------------------+
> > | Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer
|
> >
+-----------------------+------------------------+-------------------+
> > |          XML in a  Nutshell, 2nd Edition (O'Reilly, 2002)
|
> > |              http://www.cafeconleche.org/books/xian2/
|
> > |  http://www.amazon.com/exec/obidos/ISBN%3D0596002920/cafeaulaitA/
|
> >
+----------------------------------+---------------------------------+
> > |  Read Cafe au Lait for Java News:  http://www.cafeaulait.org/
|
> > |  Read Cafe con Leche for XML News: http://www.cafeconleche.org/
|
> >
+----------------------------------+---------------------------------+

Received on Thursday, 9 January 2003 19:21:53 UTC