I applaud the effort to remove the "bugs" from the restriction model.  I
think they really were a hindrance to the use of complextype restriction.
On the flip side, a lack of rules for restriction is unfortunate.  I think
schema is used pretty much exclusively as a bottom up "lego block" tool in
terms of data modeling.  It does well at that.  But a restriction model, say
for example managing a logical model and a physical or contextual one, is
not there.  And complextype restriction is the problem.  I have yet to have
a client that uses complextype restriction.

http://www.w3.org/2005/05/25-schema/OAGi.html see "What features of XML
Schema 1.0 don't meet your needs?"

A lot of folks try to use UML to XSD conversion for logical/physical
generated models.  Some tools do this ok, but most require you to allow the
tool to make some schema design decisions (meaning less control).  It would
be nice to have complextype restriction become a better alternative.

Of course maybe I have this all wrong.  Perhaps the lack of rules will give
some freedom and lead to some interesting implementations of this underused
feature.  I would love to see that happen.

Paul Kiel



===================================
W. Paul Kiel
xmlHelpline.com Consulting
paul@x...
work: 919-846-0224
cell: 919-449-8801
website: http://www.xmlhelpline.com
Your helpline for xml solutions.
===================================




-----Original Message-----
From: xmlschema-dev-request@w... [mailto:xmlschema-dev-request@w...] On
Behalf Of Michael Kay
Sent: Wednesday, July 15, 2009 2:30 PM
To: 'Costello, Roger L.'; xmlschema-dev@w...
Subject: RE: [XML Schema 1.1] No changes to derive-by-restriction, right?
(just a simplification of its description in the specification)

> 
> Derive-by-restriction behaves the same in 1.1 as in 1.0, right?
> 
> The only change is a simplification of its description in the 
> specification, right?
> 

The 1.0 specification gave detailed rules for what restrictions were
legitimate, and these rules prohibited some restrictions that were perfectly
reasonable. The 1.1 specification avoids giving detailed rules, and
therefore avoids these problems.

This rather puts the onus on the implementor to devise their own rules, and
of course there's a risk they'll get some corner cases wrong - but that's
better than requiring them to implement bugs enshrined in the spec.

Regards,

Michael Kay
http://www.saxonica.com/
http://twitter.com/michaelhkay