- From: Jonathan Marsh <jmarsh@microsoft.com>
- Date: Mon, 29 Mar 2004 13:19:48 -0800
- 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