RE: XInclude question

> -----Original Message-----
> From: Patrick Schmitz [mailto:patrick.schmitz@cwi.nl]
> Sent: Friday, June 29, 2001 9:36 AM
> To: Jonathan Marsh
> Cc: Patrick Schmitz (CWI); www-xml-xinclude-comments@w3.org
> Subject: RE: XInclude question
> 
> Thanks for our response. Can you also comment on the general model
issues,
> comparing a structurally nested document (as I want) to a merged one
(as
> XInclude seems to want)? I presume that these general model issues
have
> come
> up before, and I would like to hear "the other side" before I conclude
> that
> XInclude and the associated philosophy just does not serve my
purposes.

XInclude is intended to merge infosets in a more-or-less transparent
fashion.  Structurally nested documents sound more like linked documents
to me, which could (but don't have to be) modeled using nesting at the
Infoset level.

> Thanks again for taking time on this - Patrick
> 
> P.s. on the issue of ID clash, I am thinking not just of the case
where
> the
> IDREF target is not in the result infoset (as you describe), but more
the
> case where the target is there, along with another independent element
> (from
> some other doc) that happens to have the same ID. In a merged infoset,
the
> IDREF should point to both elements, yes?

Yes, this also was clear.

> To resolve this kind of case, I propose a hierarchic ID-space
resolution
> mechanism that respects scope. Thus the IDREF in one fragment will not
(by
> default) resolve against other scopes. This however depends upon some
> maintenance of the notion of the individual documents (fragments)
> associated
> with each source infoset. Is that at odds with XInclude or not?

It appears to be at odds with transparency of inclusion, and would
require the invention of additional infoset properties.

> -----Original Message-----
> From: Jonathan Marsh [mailto:jmarsh@microsoft.com]
> Sent: vrijdag 29 juni 2001 17:46
> To: Patrick Schmitz
> Cc: Patrick Schmitz (CWI); www-xml-xinclude-comments@w3.org
> Subject: 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 14:22:51 UTC