OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Expectations for XML Schemas 1.1 (was Re: Quick XML Schema question)



From: Jeff Rafter <jeffrafter@earthlink.net>

>Adam,

>> Is there anyway for me to specify the requirement that the inpoint be
>> numerically smaller than the out point.

>Unless you mean something like inpoint must be less than the constant 24
and
>outpoint greater than or equal to 24, no.  This is what is lovingly
referred
>to as a co-constraint.  Features like this are slated for 1.1 or 2.0

I don't expect these kinds of constraints will be in XML Schemas 1.1.   I
imagine the Schema WG will be more interested in making good on the existing
functionality (e.g. the incomplete areas such as date/times, key scoping)
rather than venturing into new areas.

Another reason not to expect it for 1.1 is that the Schematron model's
strength is that it assumes random access to the whole document, while XML
Schemas has been limited to allow streaming implementations (a respectable
goal too). So in order to be consistent with XML Schema's design, a
Schematron-like constraint language would have to limit the kinds of XPaths
allowed: there has been no discussion anywhere on this issue (except the
related issue of the XPath subset to allowing streaming processing on keys)
and whether the result is useful.

I think the Schema WG has been loathe to include any unimplemented ideas
(not of their own making!), so until there is some implementation of a
streamable co-constraint language I doubt if it would go anywhere.

And, to a certain extent, given that the embedded Schematron constraints
seem so easy to implement, the need may not be so urgent in that there is at
least a feasible solution available.   (On the other hand, the Schematron
notion of "pattern" is not completely reconcilable with XML Schema's complex
types, so the more one uses complex type derivation the more complex the
corresponding Schematron context XPaths have to be, in the absense of PSVI
type information being available in XPath. )

Cheers
Rick Jelliffe