RE: Are we losing out because of grammars? (Re: Schema ambiguitydetection algorithm for RELAX (1/4))

["Bullard, Claude L (Len)" <clbullar@ingr.com>]

So essentially, if one has a reasonably large system 
that must either push or pull data from agency to 
agency, tool to tool, one should expect now and 
in the future to write and standardize multiple descriptions of 
that data to enable validation of both co-constraints 
and grammar?

Consider, these are some very long pipelines from local 
agencies to say, government repositories.  Data modelers 
are part of this problem, but at the more serious level 
of costing delivery and calculating the dependencies 
of the processes on the validity of the data, the modeler 
may be a trivial part of the cost.  It is like the 
DePH for XML; a myth by which we simplified by not 
really the model for the cost.

Len Bullard
Intergraph Public Safety
clbullar@ingr.com
http://www.mp3.com/LenBullard

Ekam sat.h, Vipraah bahudhaa vadanti.
Daamyata. Datta. Dayadhvam.h


-----Original Message-----
From: James Clark [mailto:jjc@jclark.com]


Joe English said pretty much everything I wanted to say.  Just one
additional comment.

Rick Jelliffe wrote:

> doesn't the presence of these tricky ambiguity issues
> mean that to actually understand RELAX (and presumably certain other
schema
> languages)  requires a computer scientist not a data modeler?

If you're using RELAX for validation, it doesn't have any ambiguity
issues.  In this regard it is the same as TREX.  The ambiguity issues
only arise if you try to use it to "interpret" the document (that is
augment the information in the document by assigning each element or
attribute a label corresponding to some rule in the schema).  If you
just stick to validation, there's no issue.

I would agree with the sentiment that it's bad to inflict tricky
ambiguity issues on data modelers. Fortunately this is not inherent in
using grammars for validation.