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

[Eric van der Vlist <vdv@dyomedea.com>]

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 dream that I had was that all the different styles of inclusion would
> use one syntax for inclusion.  But it turns out that each vocabulary
> attaches its own semantic variants to modularity.  Syntactic versus semantic
> inclusion are very different beasts, analogous to C includes (older
> technology) versus Java imports (newer technology).  We've learned over time
> what to do with naming and include/imports.  NoahM explained this to me last
> year in fabulous detail when I was pushing for schema to use xinclude.
>
> So alas, the original goal of a single inclusion construct wasn't meant.

:(
 
> BTW, I do believe that the proliferation of Entities/XInclude/XLink/Schema
> modularity/XSLT modularity/?Query modularity?/others is an example of how
> the W3C does not have a centralized architecture board/committee/wg.  Why
> should an author of various xml documents that fit into an application have
> to learn 3/4/n? different syntaxes and semantics for modularity?  Sometimes
> trade-offs of functionality versus simplicity across the whole need to be
> made.  When something is designed by a number of individual committees,
> perhaps they don't see the overall complexity that can be caused by meeting
> individual goals.  I'm not suggesting that any particular WGs work is
> inappropriate, just that I don't think the whole has been taken into
> account.

As an outside observer, it's difficult for me to give a meaningful
comment ;)

The pace at which specifications are released is probably a reason for a
lack of coherence between them. When people are under pressure they tend
to focus on the specific issues behind them rather than looking for
coherency with colleagues pursuing different tracks...

I hope this is an area where outside observers can help, though.

It's by creating imaginative combinations of the many specs and
techniques that we can try to add value. 
 
> 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 ?

> I think if we had this model earlier, we could have had only 1 syntax.  But
> we weren't ready with defining various processing models and
> transformations.

Thanks for sharing these comments.

Eric
 
> Cheers,
> Dave Orchard
> 

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