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

[David Orchard <orchard@pacificspirit.com>]

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.

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.

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

Cheers,
Dave Orchard


> -----Original Message-----
> From: Eric van der Vlist [mailto:vdv@dyomedea.com]
> Sent: Tuesday, November 07, 2000 3:34 AM
> To: xml-dev@lists.xml.org
> Subject: Re: W3C XML Schema best practice : inclusions
>
>
> Rick JELLIFFE wrote:
> >
> > "Henry S. Thompson" wrote:
> > >
> > > Eric van der Vlist <vdv@dyomedea.com> writes:
> > >
> > > > My reading of this is that you can include, using
> xsd:include and a
> > > > XPointer identifying a text/xml fragment, a single
> element definition
> > > > such as:
> > > >
> > > > <xsd:element name="foo" type="ns1:bar"/>
> >
> > > Including or importing fragments would open up a whole
> complex design
> > > issue for, in my opinion, very little gain.
> >
> > It is possible to have a document that is XML Schema elements with
> > embedded XIncludes. But it is not a valid XML schema, in
> the same way
> > that an XSLT stylesheet containing XML Schema elements does
> not need for
> > the XML Schema elements to validate against the schema for
> XML Schemas.
> > But both the document with XIncludes and the XSLT document would be
> > intended, presumably, to produce valid XML Schemas after
> some processing
> > (inlining for the XInclude and the transformation of XSLT document).
>
> Yes. In both cases the "resulting infoset" as XInclude calls
> it would be
> a valid W3C XML Schema but none of the components would be.
>
> > In the case of xsd:include, it might have beeen possible to
> have used
> > XInclude, but we still would have xsd:import and
> xsd:redefine, and it
> > hardly seems worthwhile to include another namespace. And
> it would make
> > users use href rather than schemaLocation for the attribute
> name, which
> > I think would be a loss.  I don't think it is a gain for a single
> > language to be internally inconsistent. XML Schemas cannot just use
> > XInclude, because <import> and <redefine> require something
> more clever,
> > so it would not actually improve life (and might actively
> give the wrong
> > idea) to use XInclude.  I don't think the goal of namespaces is that
> > every function has one only name: namespaces allow you to include
> > islands of functionality, to compose a document type from
> pieces but in
> > this case the "include" is really a degenerate form of
> something already
> > provided ("redefine").
>
> Agreed.
>
> You were also right in your first answer, XLink would have
> been a better
> candidate than XInclude.
>
> A construct with xlink:show="embed|other|..." and
> xlink:role="xml schema
> inclusion (or redefinition) uri" would have allow to a generic XLink
> aware tool (such as future browser releases) to do something
> intelligent
> with the info whereas it will not recognize a xsd:include unless he
> knows about the specific semantic of W3C XML Schema.
>
> Disclaimer: it's just a comment ;) and maybe a best practice rule for
> designing new vocabularies taking advantage of generic mechanisms...
>
> > One approach to handling this kind of problem (if it needs to be
> > handled) would be if there were some kind of
> "rename-on-import" facility
> > so that we could derive xsd:include from Xinclude, but rename the
> > appropriate attributes.  That would take us closer to Architectural
> > Forms capabilities, and might also help with XLinks.  But that is
> > something to think about next year, I think.
>
> OK.
>
> Thanks
>
> Eric
>
> > Cheers
> > Rick Jelliffe
>
> --
> --------------------------------------------------------------
> ----------
> Eric van der Vlist       Dyomedea
http://dyomedea.com
http://xmlfr.org         http://4xt.org              http://ducotede.com
------------------------------------------------------------------------