OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: W3C XML Schema best practice : inclusions

[ Lists Home | Date Index | Thread Index ]
  • From: Rick JELLIFFE <ricko@geotempo.com>
  • To: ",xml-dev@lists.xml.org" <xml-dev@lists.xml.org>
  • Date: Tue, 07 Nov 2000 19:35:15 +0800

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

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

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.

Rick Jelliffe


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS