Home. 
.

transparent

transparent

transparent

Altova Mailing List Archives


SV: SV: Schema help

From: Bryan Rasmussen <brs@----.-->
To: "'noah_mendelsohn@--.---.---'" <----_----------@--.---.--->
Date: 11/16/2005 2:54:00 PM

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@u... [mailto:noah_mendelsohn@u...]
Sendt: 15. november 2005 19:06
Til: Bryan Rasmussen
Cc: 'Pete Cordell'; 'xmlschema-dev@w...'
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@i...>
Sent by: xmlschema-dev-request@w...
11/15/2005 03:52 AM
 
        To:     "'Pete Cordell'" <petexmldev@t...>
        cc:     "'xmlschema-dev@w...'" <xmlschema-dev@w...>, (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




From noah_mendelsohn@u... Wed Nov 16 15:53:22 2005
Received: from lisa.w3.org ([128.30.52.41])
	by frink.w3.org with esmtp (Exim 4.50)
	id 1EcPb8-0004VK-Ch
	for xmlschema-dev@lis


transparent
Print
Mail
Digg
delicious
Disclaimer
.

These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on www.altova.com/list/index.html. Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.

.
.

transparent

transparent