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

RE: XML Schema WG Comments on Last Call Draft

From: C. M. Sperberg-McQueen <cmsmcq@acm.org>
Date: 26 Feb 2004 15:11:02 -0700
To: Jonathan Marsh <jmarsh@microsoft.com>
Cc: Ashok Malhotra <ashokma@microsoft.com>, www-xml-xinclude-comments@w3.org, w3c-xml-schema-ig@w3.org
Message-Id: <1077833461.2498.138.camel@localhost>

On Tue, 2004-02-17 at 16:47, Jonathan Marsh wrote:
> Thank you for your comments.  Responses below:
 
Thank you for your responses.

...

>> These comments on the XInclude Last Call draft dated November 10,
>> 2003 are on behalf of the XML Schema WG
>> ... 
 
>> 1.  XInclude now works as an Infoset transformation.  If the
>> documents/fragments have been Schema validated the PSVI decorations
>> are removed before the inclusion takes place and the resulting
>> Infosets have to be re-validated if so needed.  We find your
>> description of the inclusion process under this constraint
>> consistent and correct but we are disappointed that you did not
>> choose to step up to the challenge of inclusions based on PSVIs.
 
> The Core WG continues to believe a full solution is a complicated
> proposition, especially because of the possibility for recursive
> includes.  Even XML Schema does not specify how to apply validation
> recursively to a PSVI.  We also are concerned about getting
> implementation experience on such a feature - none of the
> implementations by WG members are willing to implement such
> functionality.  However, we do leave open the possibility of a
> specification for accomplishing this when the knowledge and demand
> by implementers is there.

Your point taken; we are satisfied with this disposition of our
comment.

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

>> 3. Section 5 discusses support for IRIs.  Since the IRI proposal is
>> not a recommendation yet, you say you expect to issue an erratum
>> with possible changes when the IRI proposal becomes a
>> recommendation.  This is reasonable.  But, it's is a pity that the
>> IRI support has to be handled in this manner.  Do you have a
>> projected date for the erratum?
 
> That depends upon the IRI draft.  We have successfully (we hope)
> used the same strategy in Namespaces 1.1 which has recently gone to
> Recommendation.

We are satisfied with this disposition of our comment.

Thank you very much.

-C. M. Sperberg-McQueen
 on behalf of the W3C XML Schema Working Group
Received on Thursday, 26 February 2004 17:12:53 UTC

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