RE: Non-defined elements in XInclude namespace

Below...

> -----Original Message-----
> From: Elliotte Rusty Harold [mailto:elharo@metalab.unc.edu]
> Sent: Wednesday, January 08, 2003 8:00 PM
> To: Jonathan Marsh
> Cc: www-xml-xinclude-comments@w3.org
> Subject: RE: Non-defined elements in XInclude namespace
> 
> At 12:48 PM -0800 1/8/03, Jonathan Marsh wrote:
> >Thank you for bringing this problem to our attention.  We resolved
the
> >issue as follows:
> >
> >An xi:include element can contain any content EXCEPT elements in the
> >XInclude namespace other than a single optional xi:fallback element.
> >
> >A related problem was also addressed:  attributes on xi:fallback
> >elements are now explicitly treated consistently with attributes on
> >xi:include - additional attributes are allowed, but unprefixed ones
are
> >reserved for future versions of XInclude.
> >
> >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.
> >
> 
> This very well may resolve my concerns. It's hard to tell without
> seeing the final spec. If "An xi:include element can contain any
> content EXCEPT elements in the XInclude namespace other than a single
> optional xi:fallback element." means  that the XInclude processor
> throws a fatal error when such an element is encountered, then this
> is fine. However, the type of error it throws does need to be
> specified.

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."

> One side-effect: this approach does seem to require that processors
> read the children of XInclude elements to make sure there aren't any
> nested xi:include elements, even if the resource is available.

Yes.  But the alternative is some documents that succeed when a resource
is available, and produce a fatal error when the resource isn't (instead
of fallback).  The extra check may be a bit burdensome but seems safest.

> 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.

> +-----------------------+------------------------+-------------------+
> | 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 Thursday, 9 January 2003 19:14:22 UTC