Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: W3C XML Schema best practice : inclusions
Rick JELLIFFE wrote:
>
> "Henry S. Thompson" wrote:
> >
> > Eric van der Vlist <vdv@d...> 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
------------------------------------------------------------------------
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
