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?

From: Charles Reitzel <creitzel@mediaone.net>

> Sorry old thread.  Nice analysis.  I have often found it necessary to
> re-normalize based on data dynamics.
> Rules, due to their invocation at a points in time, make inroads into the
> "route" (e.g. SQL triggers).  Declarative rules *use* grammar for their
> definition and depend on "grammar valid" data on which to operate.  

I'm very glad you've wrote that, because this means I'm not the only 
one who looks at SQL all the time.

This is exactly the view I'm trying to promote ( and to implement ) last days. 
I call it 'layered schema'. I should say that to the best of my knowledge 
none of the current schema efforts ( including TREX and RELAX ) is 
pushing this direction. I'l be very happy to be wrong, because reinventing 
the wheel is a painful thing. TREX is cool, but it is really 'for validation only'
and it also gives up on types.

> Anyway, it would have never occurred to me that XML Schema should
> incorporate rules in the sense you describe.  At least not in 1.0, eh? 

Not only that, but I doubt that XSD ( or even TREX ) 
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 
the terms of 'core layer' - XSD or TREX become not a 
good 'core layer' )

Separation of the 2 layers mentioned by James Clark ( I agree 
with him that those 2 things should be separated ) does not impiles 
that those 2 layers can not *use* each other. 

I think they can and I think they should.
> To put it in perspective, SQL didn't get basic triggers until 2.0.  Now on
> version 3, SQL has got some basic OO features, even if little implemented or
> used.  Heck, most people never use triggers.  They just put it somewhere in
> the application code.

Well ... I'd say that 'constrains' are 'closer'  than 'triggers'.