Home. 
.

transparent

transparent

transparent

Altova Mailing List Archives


Re: conditional expression

From: noah_mendelsohn@--.---.---
To: "Jack Lindsey" <tuquenukem@-------.--->
Date: 7/28/2006 5:42:00 AM
Jack Lindsey writes:

> So you are saying these upcoming working drafts will support value-based 

> co-occurrence constraints?
> 
> Does this also imply that the WG has decided not to pursue the often 
> requested more seamless integration with Schematron in favour of 
reinventing 
> the wheel, but a smaller wheel?

Well, I need to be a little careful about appearing to represent the 
workgroup here, since in fact we won't formally know what's in any working 
drafts until the workgroup votes to publish one.  Furthermore, the whole 
purpose of a working draft is to solicit comment, so if people feel that 
whatever is in the WD is the wrong design point, then we'd expect to get 
comments and they would surely get very serious consideration.

With those caveats, let me say some things about what I personally take to 
be the state of play on this issue.  First of all, the WG is very aware 
not only of the good experiences that people have had with Schematron, but 
of a general interest in not reinventing the wheel, and for some users a 
specific interest in being able to come as close as possible to using 
exactly the stylesheets that they may have already written using 
Schematron.  There are also some forces pulling in other directions that 
we need to consider and balance.  For perfectly good reasons, schematron 
in XML schema is usually deployed inside of an <xsd:appinfo> element. 
That's one of the few extension points in Schema 1.0, and Schematron uses 
it.  Still, <xsd:appinfo> is architecturally barely more than a structured 
comment in XSD terms, and having major features burried in comments is at 
best a compromise.  Furthermore, XSD has abstractions like types that are 
used quite consistently and are quite deeply integrated architecturally. 
To put it simply, in Schema 1.0, if two elements have the same type, then 
there are the same restrictions on their content.  This fact is used by 
systems like XQuery, and by various databinding tools (e.g. you might 
create a single Java type for each schema type, and Java member variables 
for each element instance.)   From a co-constraint point of view it's 
worth asking with some care:  which constraints, if any, should be 
integrated into the schema type system, and which should be done in a 
completely orthogonal layer such as Schematron?

I don't want to say conclusively where the schema WG is going to go in 
balancing these factors, in part because it isn't completely decided even 
for the next working draft, but I did want to point out that there are 
good reasons why the analysis needs to be a bit more careful than "can we 
just bless Schematron?"  That said, and here again I'm speaking for myself 
and not the workgroup, I think it's quite likely that Schema 1.1 will at 
least encourage processors to support the existing appinfo-based embedded 
Schematron.  The question is whether we will stop there, or whether we 
will try to additionally provide some syntax that offers some similar 
capabilities in a manner that might have truly first class syntax in the 
XML Schema language, and more important architecturally, a stronger 
relationship to the Schema type system.

Having gone that far, I would like to make a fairly strong plea that we 
not hold this debate in the abstract.  The advantage of having a working 
draft, which I hope will come reasonably soon (for some definition of 
reasonably soon), is that we will have concrete proposals to debate.  I 
think that the right time to look at the tradeoffs in detail is after we 
have a public working draft with specific proposals on both syntax and 
semantics.

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








"Jack Lindsey" <tuquenukem@h...>
07/27/2006 11:56 PM
 
        To:     noah_mendelsohn@u..., xmlschema-dev@w...
        cc: 
        Subject:        Re: conditional expression


Noah:

So you are saying these upcoming working drafts will support value-based 
co-occurrence constraints?

Does this also imply that the WG has decided not to pursue the often 
requested more seamless integration with Schematron in favour of 
reinventing 
the wheel, but a smaller wheel?

Cheers
                  Jack Lindsey



>From: noah_mendelsohn@u...
>To: George Cristian Bina <george@o...>
>CC: Debora Vanni <debora.vanni@t...>, xmlschema-dev@w...
>Subject: Re: conditional expression
>Date: Wed, 26 Jul 2006 09:52:42 -0400
>
>
>Requests for this or similar function are made regularly.  As I have
>mentioned on this list before, the XML Schema WG is working hard on
>proposals for features that would provide for expressing such constraints
>in the upcoming version of the XML Schema Language, i.e. XML Schema 1.1.
>If you're interested, look for features in upcoming working drafts that
>allow you to express "co-occurrence constraints".
>
>Noah
>
>--------------------------------------
>Noah Mendelsohn
>IBM Corporation
>One Rogers Street
>Cambridge, MA 02142
>1-617-693-4036
>--------------------------------------
>
>
>
>
>

_________________________________________________________________
Play Q6 for your chance to WIN great prizes. 
http://q6trivia.imagine-live.com/enca/landing




From Eduardo.Gutentag@S... Fri Jul 28 18:22:55 2006
Received: from lisa.w3.org ([128.30.52.41])
	by frink.w3.org with esmtp (Exim 4.50)
	id 1G6Wz9-0002S8-NC
	for xmlschema-dev@li


transparent
Print
Mail
Like It
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