- From: Jonathan Marsh <jmarsh@microsoft.com>
- Date: Fri, 4 Jan 2002 17:43:28 -0800
- To: "Patrick Schmitz (CWI" <patrick.schmitz@cwi.nl>
- Cc: <www-xml-xinclude-comments@w3.org>
I'm cleaning up XInclude CR loose ends, and found that we never officially replied to the problem about [references]. We decided to add a section describing how the [references] property is fixed up. In short, we take the [attribute type] property as definitive and recalculate the [references] property. Thanks! Jonathan Marsh > These are good questions. I'm cc'ing the official comments list. > > We lumped the ID problem in with validation, which has similar > properties. That is, two valid documents (according to an XML Schema or > DTD) merged together will not necessarily result in a valid document. > Two documents with unique IDs merged together will not necessarily > result in a document with unique IDs. Fixing up valid documents (or > even detecting that they are invalid) is beyond the scope of XInclude. > XML Schema has made some comments related to this issue and we will be > revisiting it. > > However, you correctly point out that the references property for IDREF > or IDREFs type elements raises some interesting questions that XInclude > does not answer. Specifically, if a portion of a document is included > which contains a reference to an element not in the included portion, > does the reference "suck in" the entire document? Is the reference or > the referenced element trimmed in some way? Does any error condition > result? These questions need to be considered by the WG. > > The simplest and most draconian solution is that any validation-derived > information (including IDREF references) simply gets tossed during > inclusion, resulting in an infoset that appears to be un-validated > (which is better than having incorrect validation information in it). > Subsequent application of an XML Schema (or a DTD through real or > simulated serialization and reparsing) would be needed to reconstruct > validation and type information. I hope we can do a little better than > this though... > > The references property (for IDREF or IDREFs) was added recently in the > infoset, after we had "resolved" our ID issues with XInclude. We missed > the impact of this change on XInclude. Thanks for bringing this to our > attention. > > > -----Original Message----- > > From: Patrick Schmitz [mailto:cogit@ludicrum.org] > > Sent: Friday, June 29, 2001 5:28 AM > > To: Jonathan Marsh > > Cc: Patrick Schmitz (cogit); Patrick Schmitz (CWI) > > Subject: XInclude question > > > > Hi Jonathan - > > > > I have a question about XInclude. You and I met once when our > > respective W3C FtF meetings coincided in Antibes. I worked for MSFT until > > very recently, and am now doing some research as a visitor at CWI in > > Amsterdam. Part of my interest here is in structured or nested documents > > (especially for nested, timed documents, and annotations to timed > > documents). Naturally, I looked over XInclude to understand how it might > > relate to my work. > > > > The question is this: in the XML Information set spec, attributes of > > type IDREF will have a resolved element info-item reference in the > > reference property. XML Include describes the general transform to build > > a merged info set, but I did not find any language that describes what will > > be done about ID clash in the result infoset. > > > > By ID clash I mean the case in which included documents/fragments > > contain element(s) with associated ID value(s) that are the same as the > > ID value of an element in the including document, or of an element in > > another document/fragment included elsewhere. > > > > The infoset spec says that the references property will have no value > > if the IDREF is not valid. In a single XML doc I know that multiple, > > identical ID's is an error, but I do not see a strict definition of > > "error" association with XInclude processing. All of the source documents > > (infosets) could be correct and legal w.r.t. ID values, but the combination > > could easily be invalid. > > > > 1) What is intended to happen when there is ID clash in the result > > infoset? Will the references property contain multiple element info-item > > references, or will the property have no value? > > > > 2) Is there any proposed remedy to be implemented by the info set > > transform in this case? > > > > I have been working on a model for nested documents that is more DOM > > centric (that's just the way I am used to thinking about it). In my model, > > the xi:include equivalent is something more akin to a smil:ref element > > (declares media with an href to the media resource), or the html:iframe > > element (equivalent to smil:ref for the purpose of this discussion). In > > my model the included content is parsed and joined with the hosting document, > > but it is rooted *under* the including element, rather than *replacing* the > > including element as XInclude describes. > > > > This is useful for a number of reasons, including control over how the > > included material is presented, but moreover as a means of handling > > structured ID references (an idea I have been working on with a few > > folks here). The structured ID reference introduces a hierarchy of ID > > resolution, and allows references across the document boundaries in a > > nested document. > > > > Thus given doc bar.xml (sparse and sloppy for the purpose of discussion) > > > > <xml ...> > > <something id="joker" .../> > > ... > > </xml> > > > > which is included by doc foo.xml, sparsely indicated here: > > > > <xml ...> > > <my:include id="inclBar" href="bar.xml"/> > > <something id="joker" .../> > > ... > > <bind from="inclBar.joker" to="joker" .../> > > </xml> > > > > Assume the "from" attribute on the hypothetical <bind> element is > > declared to be of type ID-STRUCT-REF which is my new structured id ref > > mechanism. Sorry for the vagueness - I am still working on the details. > > > > Then the hypothetical binding element in foo.xml can actually > > reference the element with id="joker" in bar.xml, *via* the including > > element. > > > > This approach solves a bunch of problems for me, but seems as well to > > be in some conflict with the model of XInclude. > > > > Can you comment at all on this? Is there someone else who would be > > good to discuss this with? I should probably hunt for the right DL for > > XInclude, but it was easier to just email you. Feel free to forward this > > as you see fit. > > > > Thanks in advance - Patrick
Received on Friday, 4 January 2002 20:44:00 UTC