W3C home > Mailing lists > Public > www-xml-xinclude-comments@w3.org > January 2003

RE: Non-defined elements in XInclude namespace

From: Jonathan Marsh <jmarsh@microsoft.com>
Date: Fri, 10 Jan 2003 10:23:27 -0800
Message-ID: <330564469BFEC046B84E591EB3D4D59C08D1D563@red-msg-08.redmond.corp.microsoft.com>
To: "Elliotte Rusty Harold" <elharo@metalab.unc.edu>
Cc: <www-xml-xinclude-comments@w3.org>

How about this?

"The content of the xi:include element may include a single xi:fallback
element; the appearance of an xi:include element or any other element
from the XInclude namespace is a fatal error.   ..."

> -----Original Message-----
> From: Elliotte Rusty Harold [mailto:elharo@metalab.unc.edu]
> Sent: Thursday, January 09, 2003 4:32 PM
> To: Jonathan Marsh
> Cc: www-xml-xinclude-comments@w3.org
> Subject: RE: Non-defined elements in XInclude namespace
> 
> At 4:13 PM -0800 1/9/03, Jonathan Marsh wrote:
> 
> >Our intention is that it be a fatal error.  Here is the actual text I
> >placed in the spec:
> >
> >"The content of the xi:include element may include a single
xi:fallback
> >element; other elements from the XInclude namespace result in a fatal
> >error. Other content (text, processing instructions, comments,
elements
> >not in the XInclude namespace) is not constrained by this
specification
> >and is ignored by the XInclude processor, that is, it has no effect
on
> >include processing, and does not appear in the [children] properties
of
> >the result infoset. Such content might be used by applications
analyzing
> >a pre-inclusion infoset, or be made available to an application
> >post-inclusion through means other than the normal infoset
properties."
> 
> That wording resolves my concerns. Thanks!
> 
> >>  Also, this makes me wonder about elements in the XInclude
namespace
> >>  other than include and fallback that do not appear inside an
> >>  xi:include element. For example, xi:some-user-element. My reading
of
> >>  the current spec is that these are simply passed along like any
other
> >>  element, but perhaps you wish to tighten that up and make these
fatal
> >>  errors too (or perhaps not). I know these are edge cases but
that's
> >>  what make spec writing tough. :-)
> >
> >Our intention is that these are fatal errors, which is inherent
(though
> >not explicit) in the wording of our resolution.
> 
> I would prefer this to be explicit.
> --
> 
> +-----------------------+------------------------+-------------------+
> | Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer |
> +-----------------------+------------------------+-------------------+
> |           Processing XML with Java (Addison-Wesley, 2002)          |
> |              http://www.cafeconleche.org/books/xmljava             |
> | http://www.amazon.com/exec/obidos/ISBN%3D0201771861/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 Friday, 10 January 2003 13:23:59 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:58:56 UTC