- From: Bryan Rasmussen <brs@itst.dk>
- Date: Wed, 16 Nov 2005 13:53:54 +0100
- To: "'noah_mendelsohn@us.ibm.com'" <noah_mendelsohn@us.ibm.com>
- Cc: "'xmlschema-dev@w3.org'" <xmlschema-dev@w3.org>, "',petexmldev@tech-know-ware.com'" <", petexmldev"@tech-know-ware.com>
I think my negative attitude towards XML Schema actually stems from my first experience of it, where I just happened to need to implement a co-occurence constraint, in which element x held a list of ids of elements of type y. I try to follow the spoilt baby method of standards evaluation, if in the first ten minutes it disappoints I will complain about it for the rest of it/my existence, whichever ends first. :) That said, if I am allowed liberal use of schematron in concurrence with XML Schema then the pain largely goes away. I think it would be more interesting to try to figure out a model for XSD and Schematron to work together, rather than to try to put context dependentcy on top of the XSD model. Not to say that I have any theory as to how that would be done beyond that which already exists. But from what you said below I somewhat doubt that XSD with context dependent validation will still be weaker than Schematron handling of context dependency. Cheers Bryan Rasmussen -----Oprindelig meddelelse----- Fra: noah_mendelsohn@us.ibm.com [mailto:noah_mendelsohn@us.ibm.com] Sendt: 15. november 2005 19:06 Til: Bryan Rasmussen Cc: 'Pete Cordell'; 'xmlschema-dev@w3.org' Emne: Re: SV: Schema help (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 Wednesday, 16 November 2005 12:56:38 UTC