RE: XInclude question

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, 29 June 2001 12:35:29 UTC