[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: W3C XML Schema best practice : inclusions
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@d...] > Sent: Tuesday, November 07, 2000 3:34 AM > To: xml-dev@l... > Subject: 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
|