RE: XInclude question

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