[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: W3C XML Schema best practice : inclusions

• From: Eric van der Vlist <vdv@d...>
• To: David Orchard <orchard@p...>
• Date: Thu, 09 Nov 2000 09:40:32 +0100

Comments below...

David Orchard wrote:
> 
> > -----Original Message-----
> > From: Eric van der Vlist [mailto:vdv@d...]
.../...
> > 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
> > ?
> >
.../...
> 
> 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.

Yes, you're right, XLink is heavily biased toward hypertext presentation
and it would have been cleaner if the "show" attribute had be from
another namespace.

This is a difference with other linking technologies worth mentioning.

> 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.

Doesn't seem that verbose ;) ...
 
> 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.

That's what I was meaning by "architecture".

One has to establish the transformation flow... 

Here you are differentiating 2 kind of beasts. The first (XInclude) one
operated on the XML infoset while the second one (XLink) operates at a
higher level on the application data model (or display) derived from the
XML infosets.

This tend to confirm that a schema (or stylesheet) inclusion would
probably be better described in term of XLink than in terms of XInclude.

This is also implementation dependent, though and the distinction would
be less pertinent for a streaming application that would build the
higher level data model directly without materializing the XML infosets.

> 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.

Go it...

Thanks

Eric
-- 
------------------------------------------------------------------------
Eric van der Vlist       Dyomedea                    http://dyomedea.com
http://xmlfr.org         http://4xt.org              http://ducotede.com
------------------------------------------------------------------------

• Follow-Ups:
  • Re: W3C XML Schema best practice : inclusions
    • From: ht@c... (Henry S. Thompson)

• References:
  • RE: W3C XML Schema best practice : inclusions
    • From: David Orchard <orchard@p...>

• Prev by Date: XML in systems development
• Next by Date: Re: SAX Proposal: new AttributesBuilder interface
• Previous by thread: RE: W3C XML Schema best practice : inclusions
• Next by thread: Re: W3C XML Schema best practice : inclusions
• Index(es):
  • Date
  • Thread