Re: Are we losing out because of grammars?

[Paul Tchistopolskii <paul@qub.com>]

To me this way is a bit different from what SQL does.

In SQL :

1. The second layer ( triggers ) is the 'slave', 
but the core layer ( create table ) is the 'owner' 

2. Not only layer 1 is using entities from layer 2, 
but layer 2 is also using entities from layer 1 - and 
the result is 'kinda elegant'.

In your design it looks like Schematron is the 'owner', 
and TREX is the 'slave' == library for regular expressions 
( because this is what TREX really is ). This gives  
us the "high-level language" == Schematron 
driving the show, and I don't like it.

Your design is very consistent. I just think it is 
not what happens in SQL.

Maybe it is also possible to attach 
the Schematron rules to TREX patterns ( like 
perl is attaching functions to the parts of 
regular expressions ) but I'm not sure that the 
resulting mix will be as good as it is in SQL.

I'm sorry - my English is not sufficient for explaining the 
subtile differences I'm trying to talk about.

Rgds.Paul.

----- Original Message ----- 
From: James Clark <jjc@jclark.com>

> > 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.
> 
> James