Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: W3C XML Schema best practice : inclusions
 David, Thanks a lot for your detailed explanation that formalizes so well things I was obscurely perceiving ! (comments inline) David Orchard wrote: > > 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. Isn't it also a matter of architecture ? I understand roles as defining the way to handle the links. Couldn't I define a http://whatever.org/linkroles/include/#core role that would make supporting applications merge the infoset of my document as XInclude specifies it ? And a http://whatever.org/linkroles/include/#xmlschema which would make its supporting application take care of the semantics of W3C XML Schema ? It can seem like a trick, but a toll (like a browser) seeing such a link could be expected to do something clever depending on the xlink:show attribute (at least to display it as a link) which will not be the case if it sees xsd:redefine except if it has been hard coded to understand W3C XML Schema. > 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. As an outside observer, it's difficult for me to give a meaningful comment ;) The pace at which specifications are released is probably a reason for a lack of coherence between them. When people are under pressure they tend to focus on the specific issues behind them rather than looking for coherency with colleagues pursuing different tracks... I hope this is an area where outside observers can help, though. It's by creating imaginative combinations of the many specs and techniques that we can try to add value. > 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 like a this vision ! Is something that is planed ? > 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. Thanks for sharing these comments. Eric > Cheers, > Dave Orchard > -- ------------------------------------------------------------------------ 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
|
|||||||||
