Re: Choice

Ashok wrote:
> I'm surprised to see you talking about XSLT as a means for adding
> declarative constraints. Don't you mean Xpath/Xquery?

There's a limit to what XPath (even 2.0) can do (at least based on the
current Working Drafts). For example, you can't declare variables in
XPath, or functions, which are necessary (I think) for some kinds of
checks that you might want to make.

Of course you *can* do that in XQuery, so that would certainly be a
possibility, if you didn't mind the non-XML syntax (I don't think that
XSLT 2.0 and XQuery are very different except in terms of their
syntax).

I think what I have at the back of my mind is three levels:

 - XML Schema
 - XML Schema + XPath
 - XML Schema + XPath + other languages

with validators free to choose which level to implement or to use on a
case-by-case basis. For example, since MSXML already has support for
XPath, XSLT, JScript and so on, it could check constraints at all
three levels, with user options to limit the validation to only the
XML Schema level or only XML Schema + XPath if performance was an
issue.

Noah wrote:
> I think we generally agree. I still have some suspicions regarding
> XSL performance, and the degree to which tools can "grok" what a
> stylesheet is doing. If I want to say: "either this attribute or
> those elements" or "the integer value of this attribute must match
> the number of elements that occur as children", I'm not sure it
> should require a theorem prover for a tool to figure out what's
> going on.

Definitely, if you can come up with a neat declarative way of
expressing the common constraints like the ones you mention, then that
method should be incorporated into the existing XML Schema framework.

Ideally, the powerful rule-based capabilities wouldn't be used at all,
but as you said previously, there's always going to be something that
you can't do through standard schema mechanisms. In my mind, it's
better having a standard way of expressing those constraints than it
is to not have anything at all to express those constraints, even if
it means that validators don't use it when they need to validate in
streaming or high-performance contexts.

Cheers,

Jeni

---
Jeni Tennison
http://www.jenitennison.com/

Received on Monday, 11 March 2002 12:38:43 UTC