W3C home > Mailing lists > Public > www-xml-xinclude-comments@w3.org > July 2000

RE: XInclude WD 22-March-2000 comments

From: Jonathan Marsh <jmarsh@microsoft.com>
Date: Tue, 25 Jul 2000 13:34:11 -0700
Message-ID: <116DFD732FA92E4D9B647C8EEF6DAF1015E2AE@red-pt-02.redmond.corp.microsoft.com>
To: "'Steve Rowe'" <sarowe@textwise.com>, www-xml-xinclude-comments@w3.org
Thanks for the comments!

> -----Original Message-----
> From: Steve Rowe [mailto:sarowe@textwise.com]

> 1) XInclude-54-syntax: If you publish another working draft, you might
> consider adding rationales for choosing either the element or the
> attribute syntax.  In favor of the element syntax, XInclude is in
> control of the expected child nodes of an include element (from a
> pre-inclusion validation perspective).  Also in favor of the element
> syntax, because XInclude processing precedes application consumption,
> the inclusion element type is irrelevant: it could be a comment about
> or description of (choice: purpose, included element type, etc.); by
> choosing the attribute syntax over the element syntax, you imply that
> that XInclude will be employed as a (normative) part of other
> vocabularies, rather than as a supplemental vocabulary which can be
> mixed with other vocabularies at will.

By the next draft, we will (must) have settled this basic syntactic
question.  I take your comments as support for element syntax.  The final
sentence is a great summary of the design decision we face, and for me is a
powerful motivator for the return to element syntax.

> 3) Section 3.2 (Acquiring resources to be included): How can different
> character encoding of the children of included elements be "taken into
> account" if it's not preserved in any way?  If XInclude will not
> mandate that the encoding of included nodes be the same as those of
> the source infoset, then it should at least record the fact that there
> might be a problem.  This kind of thing really belongs in the Infoset.

The infoset preserves this information in the form of entity start/end
markers.  We are considering suggestions for retaining entity start/end
markers, doing any fixup necessary, and being a lot more rigorous in our
description of infoset modifications.

> 4) Section 3.3 (Merging infosets): "The include element, its
> attributes and any children, are not represented in the result
> infoset".  I think you should include an example to underline this;
> it's a big deal.

Good suggestion.
 
> 5) Typos:

Thanks, I fixed them all.

- Jonathan Marsh
Received on Tuesday, 25 July 2000 16:35:20 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:09:29 UTC