[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Are we losing out because of grammars?
- From: Paul Tchistopolskii <firstname.lastname@example.org>
- To: James Clark <email@example.com>
- Date: Thu, 01 Feb 2001 00:12:04 -0800
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.
----- Original Message -----
From: James Clark <firstname.lastname@example.org>
> > 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.