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]

Re: Are we losing out because of grammars?

Paul Tchistopolskii wrote:
> ----- Original Message -----
> From: K.Kawaguchi <k-kawa@bigfoot.com>
> >
> > > is a good layer to build upon. I'm not saying that XSD or TREX
> > > is a bad thing. I'm saying that it is not a good thing for
> > > the logical layering ( when trying to express the  rules in
> >
> > Would you elaborate it a little more, please? (And also, how about RELAX?)
> I'd prefer it another way.
> 1. Let's assume that I have some schema, expressed in terms of RELAX.
> ( SQL 'core' == simple CREATE TABLE )
> 2. Now I want to write some 'more complex' rules / constraints a-la Schematron
> ( SQL 'layer 2' == constraints and / or  triggers ).
> 3. I want to write 2 sometimes using the entities which I've defined at the step 1.

For TREX, at least, I can think of several ways in which you could
integrate it with something like Schematron. For example, you could add
a <validate> element to Schematron that would occur as a child of <rule>
just like <assert> and <report>.  The semantics would be an assertion
that the tree rooted at the context node matched the TREX pattern in the
<validate> element.  A more elaborate possibility would be to have a
top-level element (ie child of the schema element) that defines named
TREX patterns, then add an XPath extension function that tests whether
the tree rooted at the current node matches a particular named pattern;
you would probably also need some way to give a helpful message
pinpointing how it failed to match.