W3C home > Mailing lists > Public > www-xml-xinclude-comments@w3.org > March 2004

RE: XML Schema WG Comments on Last Call Draft

From: Jonathan Marsh <jmarsh@microsoft.com>
Date: Mon, 29 Mar 2004 13:19:48 -0800
Message-ID: <DF1BAFBC28DF694A823C9A8400E71EA20314115C@RED-MSG-30.redmond.corp.microsoft.com>
To: "C. M. Sperberg-McQueen" <cmsmcq@acm.org>
Cc: "Ashok Malhotra" <ashokma@microsoft.com>, <www-xml-xinclude-comments@w3.org>, <w3c-xml-schema-ig@w3.org>

The XML Core WG has accepted your request to provide a place for the
xi:include elements in the resulting infoset.  Here is a draft of the
significant part of the text I'm proposing to replace the Boolean
[included] property:

The inclusion history of each top-level included item is recorded in the
extension property [include history]. The [include history] property is
a list of element information items, representing the xi:include
elements for recursive levels of inclusion. If an [include history]
property already appears on a top-level included item, the xi:include
element information item is prepended to the list. If no [include
history] property exists, then this property is added with the single
value of the xi:include element information item.

We note that we don't expect to see implementation fully exposing this
property in our upcoming CR, but that's no worse a match with current
implementations than the previous [included] property.

> -----Original Message-----
> From: C. M. Sperberg-McQueen [mailto:cmsmcq@acm.org]
> Sent: Thursday, February 26, 2004 2:11 PM
> To: Jonathan Marsh
> Cc: Ashok Malhotra; www-xml-xinclude-comments@w3.org; w3c-xml-schema-
> ig@w3.org
> Subject: RE: XML Schema WG Comments on Last Call Draft
> On Tue, 2004-02-17 at 16:47, Jonathan Marsh wrote:
> > Thank you for your comments.  Responses below:
> Thank you for your responses.
> >> 2.  In our comments on the last draft we said :
> >> "(3) We consider it a mistake to erase all record that XInclude
> >> processing has occurred. This damages the usability of this
> >> specification for many applications, such as distributed editing,
> >> document packaging, and so on."  Your reaction to this comment was
> >> to point out that most of the Infoset properties were optional and
> >> implementations were free to maintain such information if they
> >> wished.  We would prefer a better architected solution to this
> >> issue.
> > We did add a simple Boolean property [included] (see Section 4.5)
> > which records the fact that inclusion has occurred.  Did you
> > consider this property insufficient?  We would like to hear your
> > thoughts on this issue before we make a final disposition of this
> > issue.
> Oops.  We appear to have overlooked this property in our review (owing
> in part, perhaps, to a formatting inconsistency which we believe has
> now been fixed).
> We discussed this topic at some length during our working group
> meeting today, and reached consensus on it.  We agree that the
> addition of the [included] property is a step in the right direction.
> But as currently described the [included] property doesn't seem quite
> sufficient for the applications we mentioned in our comment; what
> seems to us necessary (and sufficient) is something that would allow
> the XInclude process to be reversed or rolled back.  Various ad hoc
> augmentations (provide the URI which was the value of the href
> attribute on the xi:include element, provide other bits of
> information, etc.) came immediately to mind, and quickly proved
> unsatisfactory.  But we note that if the post-Xinclude infoset (PXI)
> is defined as including the original element information item of the
> xi:include element, then rollback is possible, and the description of
> the PXI is straightforward.
> So we suggest that the [included] property be replaced by a property
> whose value is the element information item of the xi:include element.
> We note that API designers may make this information (the EII of the
> xi:include element) accessible in any way they like, or may choose not
> to make it accessible.  The XInclude specification, being
> infoset-based, not API-based, does not need to prescribe or proscribe
> anything here.
Received on Monday, 29 March 2004 16:20:09 UTC

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