W3C home > Mailing lists > Public > xmlschema-dev@w3.org > November 2005

Re: SV: Schema help

From: <noah_mendelsohn@us.ibm.com>
Date: Tue, 15 Nov 2005 13:06:00 -0500
To: Bryan Rasmussen <brs@itst.dk>
Cc: "'Pete Cordell'" <petexmldev@tech-know-ware.com>, "'xmlschema-dev@w3.org'" <xmlschema-dev@w3.org>
Message-ID: <OFEB4EEEB1.5F2B5484-ON852570BA.0062511D-852570BA.00636D6C@lotus.com>

(writing for myself and not officially for the W3C XML Schema WG)

For what it's worth, I think those of us who are active in designing the 
schema language are well aware of the good reasons why co-occurrence 
constraints are important, and that XML Schema 1.0 does not provide 
adequate support for them.   Our ability to do better in future versions 
of the Schema language, and to have improvements out in a timely manner, 
will depend to a significant extent on the degree to which W3C members 
contribute the staffing needed in the workgroup to do the necessary design 
and specification. 

Co-occurrence constraints have been near the top of our "to do" list for 
awhile, but they are also one of the bigger and more potentially 
disruptive changes to attempt.  If you study the design space a bit, 
you'll find that different users have somewhat different needs.  For 
example, some users are happy with just occurrence-based constraints 
(either this attribute or that element), and some need value-based 
constraints (if this attribute has content "X" then that element must/must 
not exist), and some even need value-based bounds (if count="10" then 
there must be exactly ten child elements).  Furthermore, there are some 
solutions that may be convenient for schema authors, but that might not be 
optimizable to the same degree that the existing schema language is (I 
think you'll be seeing reports of more high performance schema 
implementations in the forseeable future.)  Any change we make is almost 
sure to introduce some degree of interoperability problems with already 
deployed Schema 1.0 processors.

So, I wanted to make clear that there is no need to try and convince 
people that there's a need.  It's been well understood in the Schema 
community since before Schema 1.0 shipped.  Then again, what there isn't 
is completely consensus on is exactly who has which flavor of the problem, 
and which solutions would meet an 80/20 point in providing good value for 
reasonable cost and complexity.  In any case, the gating factor at this 
point is almost surely a commitment by the W3C membership to invest in 
answering these questions.  Not to say the existing WG members may not 
try, but the group is small, and this is not the only high-priority 
request we've received.  As I say, it remains near but not quite at the 
top of our list of big things in which to invest.  FYI:  examples of areas 
which we are working on include trying to come up with mechanisms to 
facilitate versioning of XML Vocabularies, and also changes to mitigate 
UPA problems that arise when using Wildcards near optional content.  There 
has also been a lot of work done to clean up and clarify the Datatypes 
portion of schemas.

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------








Bryan Rasmussen <brs@itst.dk>
Sent by: xmlschema-dev-request@w3.org
11/15/2005 03:52 AM
 
        To:     "'Pete Cordell'" <petexmldev@tech-know-ware.com>
        cc:     "'xmlschema-dev@w3.org'" <xmlschema-dev@w3.org>, (bcc: 
Noah Mendelsohn/Cambridge/IBM)
        Subject:        SV: Schema help







>Yes, this has come up a number of times recently, but I personally didn't 

>find the solutions particularly appealing!

>Maybe people that want to do this sort of thing should consider
re-modelling 
>their data so that it works to XSD's strengths. 
I found this amusing in a twisted way, it struck me that working to XSD's
strengths was synonymous with producing particularly ugly XML. 

><task>
>    <!-- common task elements here -->
>    <taskType1>
>        <!-- Task 1 things -->
>    </taskType1>
></task>

>or:

><task>
>    <!-- common task elements here -->
>    <taskType2>
>        <!-- Task 1 things -->
>    </taskType2>
></task>

I'm sorry but are you suggesting that task has a choice of taskType1
taskType2 and so forth? Sometimes I think the worse thing that was ever 
put
in the xml spec was that thing about verbosity not being a problem.


Of course I've been ranting this for years (the anti xml schema stuff), 
they
called me mad at the academy, etc. etc. 

Cheers,
Bryan Rasmussen
Received on Tuesday, 15 November 2005 18:06:17 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 11 January 2011 00:14:51 GMT