Re: more grist

[James Clark <jjc@jclark.com>]

"Henry S. Thompson" wrote:
 
> "Simon St.Laurent" <simonstl@simonstl.com> 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