Re: more grist
"Henry S. Thompson" wrote: > "Simon St.Laurent" <simonstl@s...> writes: > > > Then there's the matter of driving the deeply unpopular (in many quarters) > > W3C XML Schema specification into every other W3C specification. At a time > > when XML Schema is facing (widely welcome) competition from other > > specifications, integrating it with other W3C specifications feels like a > > major risk, if not an outright political move to push XML Schema across the > > board. > > Two points, both factual: ... > 2) None of the competition, for all their many admirable quarters, > address the type assignment issue at all. All the other W3C spec's at > issue _require_ type assignment. I think it's important to distinguish simple type assignment and complex type assignment. In XML 1.0 terms simple type assignment is analagous to reporting the type of attributes; the closest analogy to complex type assignment on the other hand seems to be reporting the name of the parameter entity containing the content model for the element. I would dispute that all other W3C specs have a requirement for *complex* type assignment. Admittedly their requirements documents may mention support for XML Schema complex types, but I think in many cases this is more a matter of trying to be a good W3C citizen and support this feature of XML Schemas because it's there: the PSV infoset has this information, so they feel they have to support it. For example, the type system of the XML Query Algebra has no notion of a named complex type hierarchy. Complex type assignment feels like it's trying to build a data-binding facility into the Schema language. I think this is a mistake. Data-binding is useful, but why does it have to be built-in to the Schema language? Simple type assignment seems much more obviously useful to me. I think many other W3C specs (such as XML Query) really do need it. However, it doesn't seem to me to be hard to layer simple type assignment on top of TREX with an additional spec called say TREX Datatype Assignment (TDA). TDA would describe a constraint on TREX patterns that would be sufficient to allow assignment of datatypes to be done unambiguously, without lookahead and in a single pass. It would also specify a global attribute that a TREX pattern would use on its document element to declare this (eg tda:unambiguous="true"). The interesting problem is to find a constraint that allows as much as possible whilst still being easy to check statically. I've just finished implemented the checking for one possible such constraint; so far, it looks quite promising. It would even be possible to layer complex type assigment on top of TREX (add a global attribute to trex:element specifying a QName), but nobody has asked for that yet. James
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