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?



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.  Rules
layered over a schema makes architectural and logistical sense.  Sometimes
the schema must make accomodations for the rules that will be applied to it.

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? 

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.

take it easy,
Charles Reitzel


>On Mon, 29 Jan 2001, Rick Jelliffe wrote:
>I think there are two kinds of schemas and 
>therefore schema languages: one tries to express what 
>is true of all data of that type at all times (e.g.
>for storage and 80/20 requirements) and another tries 
>to express the things that make that particular information 
>at that particular time and context different
>from other data of the same type.  One tries to 
>abstract away invariants, the other tries to find  
>abstractions to express these variations.
>
>The first kind is a map, the second kind is a route.  The 
>first kind is good for automatically generating interfaces 
>and for coarse validation, the second kind is what is required 
>for data-entry and debugging all data at all. (As for the 
>status quo, I don't believe XML Schemas and DTDs pay much 
>or any attention to this second kind of schema: maybe TREX 
>and RELAX do a little bit and I hope Schematron is closer 
>to the other end of the spectrum.)