> The reference is W3C-member restricted.

Right, I forgot about that.  I'll fire the proposal text off to rick 
personally, because his input would be a good data point for the 
WG...since this is the main topic for the telcon on friday.

> It might be that we've reached the stage where we can't afford to do 
things
> properly so we have to do them cheaply. If that's the case, then this is
> probably the right way forward. However, one needs to be aware of its
> limitations.

Having the schema WG bless a subset of ISO schematron for use in appinfo 
is also not my prefered approach, but I have proposed it because: 1) it 
does handle many of the important use cases and 2) people are currently 
doing this already, and it would be good if W3C somehow acknowledged this.

> One way of doing co-occurrence constraints is to think in terms of a
> "computed xsi:type" where the effective value of xsi:type on an element 
is
> computed as the result of an XPath expression in the schema, applied to 
the
> element instance as context node. This expression can default to
> "@xsi:type", so the current xsi:type facility becomes just a special 
case.

This is what some co-constraints proponents have called "conditional 
types".  While this approach has many things going for it, I think it has 
one potential drawback.  It is unclear how data binding tools would 
support the conditional assignment of types.  I'm not saying that it 
couldn't be done but I've yet to seen anyone spell out how to handle it. 
Mind you, I'm not the biggest fan of data binding tools...but my user 
community feels they are very important so I'd like to know what the 
binding tool vendors would do with conditional types before walking too 
far down that path.

pvb

From mike@s... Thu Mar 09 19:06:40 2006
Received: from aji.w3.or