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: Eric van der Vlist <vdv@dyomedea.com>
  • To: "xml-dev@lists.xml.org" <xml-dev@lists.xml.org>
  • Date: Tue, 07 Nov 2000 12:34:05 +0100

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


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.




> Cheers
> Rick Jelliffe

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


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

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