xml-dev - RE: W3C XML Schema best practice : inclusions

[David Orchard <orchard@pacificspirit.com>]

No problem.  My comments inline as well.

> -----Original Message-----
> From: Eric van der Vlist [mailto:vdv@dyomedea.com]
> Sent: Wednesday, November 08, 2000 9:58 AM
> To: David Orchard
> Cc: xml-dev@lists.xml.org
> Subject: Re: W3C XML Schema best practice : inclusions
>
>
> David,
>
> Thanks a lot for your detailed explanation that formalizes so well
> things I was obscurely perceiving !
>
> (comments inline)
>
> David Orchard wrote:
> >
> > Eric,
> >
> > One of the very original motivators for XInclude was to
> create an inclusion
> > mechanism that could be used by any vocabulary, but
> particularly the W3C
> > vocabularies of schema, transform and xlink.  The original
> version that I
> > created in April '99 was based upon XLink.  I originally
> called this YAXI
> > (Yet Another XML Inclusion).  But XLinks turned out to be
> in appropriate for
> > modelling because almost all the attributes of XLink at the
> time were not
> > appropriate for inclusions - like role, title, show,
> actuate.  Indeed both
> > complex and simple xlinks were tried.  You can think of it
> as trying to
> > refine XLink by fixing attribute values.  The real clincher
> was the no-holds
> > barred fight in XML Link about whether XLink had a
> processing model or not.
> > The no processing model won.  So it would have been
> confusing to create an
> > inclusion syntax with a processing model upon a syntax that
> explicitly
> > avoids the use of a processing model.  Imagine: Consume
> this xlink if
> > attribute x has value y, but leave it in the infoset if
> there are any other
> > values.  JonathanM of MSFT provided some key insights on this.
>
> Isn't it also a matter of architecture ?
>
> I understand roles as defining the way to handle the links.
>
> Couldn't I define a http://whatever.org/linkroles/include/#core role
> that would make supporting applications merge the infoset of
> my document
> as XInclude specifies it ?
>
> And a http://whatever.org/linkroles/include/#xmlschema which
> would make
> its supporting application take care of the semantics of W3C
> XML Schema
> ?
>
> It can seem like a trick, but a toll (like a browser) seeing
> such a link
> could be expected to do something clever depending on the xlink:show
> attribute (at least to display it as a link) which will not
> be the case
> if it sees xsd:redefine except if it has been hard coded to understand
> W3C XML Schema.
>

The two problems that I mentioned still exist.  All of the attributes on
XLinks are specifically meant for hypertext.  XInclude is very much not a
hypertext problem, it's a tree join in memory problem.  Therefore most of
the attributes that XLink has created aren't appropriate for XInclude.

A sample from a June 2 1999 draft is:

<mylink title="n/a" id="mylink1"
   <arc id="copyrightarc" show="parsed" actuate="auto" from="linksource"
to="target"/>
   <locator role="linksource" href="#/id(mylink1)"/>
   <locator role="target" href="myurl.xml"/>
   <include arc-id="copyrightarc" processing-step="pre-transform"
orginal-node-location="replace"/>
   </mylink>

This shows the use of extended links to do inclusions.  Notice how verbose
the grammar is.

This was refined to a June 25 1999 draft follows:

<!ELEMENT xlink:include EMPTY>
<!ATTLIST xlink:include
    href           CDATA               #REQUIRED
    steps          CDATA               #IMPLIED "1"
    parse          CDATA               #IMPLIED "xml"
    role           CDATA               #IMPLIED
    title          CDATA               #IMPLIED
>

but still notice how steps, role, title don't play much of signicance.
Though the attribute form of XLink does help the issue.  Further note that
XInclude effectively defaults the steps, parse, show, and actuate flags.

That's a historical retrospective on the attempts to use xlinks both complex
and simple.

Now, the processing model is the other side of the coin.  The problem with
using role to specify an inclusion to occurr before any other processing is
it means that an XML Parser has to be completely XLink aware.  To do this
properly, we'd have to say something like XML Inclusion parsers REQUIRE
complete use of XML Links.  That means full and total support of XLinks,
simple and complex.  But XLink typically expects that xlinks will be
consumed by an application AFTER dtd/schema validation, transform, query.
So inclusions and xlinks occur in two very different places in the
processing model.

It seemed much better to create a simpler specification than XLink, put it
into a different namespace and highlight that it occurs in a specific step
in the processing model.

<big snip>
> > The next 3 things I think we need to do to really support
> inclusions:
> > 1) Define a processing model with states of processing xml documents
> > 2) Create Xpointer extensions that can reference the various states.
> > 3) Augment XInclude to specify when in the processing step
> the inclusion
> > should occur.
> >
> > Then we can augment XInclude so we can point to things in
> various states and
> > have the includes occur at various states.  And voila, we have
> > transclusions.
>
> I like a this vision !
> Is something that is planed ?

This vision is in nobody's head except mine and various assorted ramblings
like this.  So there is no W3C plan.

Cheers,
Dave