RE: What is the advantage of RELAX in comparison to Schemas?

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

Agreeing that both cases have valid uses, I would 
argue that the legacy rules are still the rules 
of consensus and that the requirement to "drag 
in a programmer" is an unfortunate side effect of 
the original implementation (eg, WYSIWYG botched  
document production by hiding an unmodifiable schema).

Keeping up multiple documents to control a single 
instance is a cost, no doubt, but spreading a single 
ineffective control across multiple processes with 
different objectives is also costly.  Again, the 
case must be made for consensus and that is harder 
than to rule by fiat.   The problem is that when 
one attempts the monolith it is likely that acceptance 
and implementation may be sparser than if only the 
simplest and easily recognized agreements are made 
(this is Berners-Lee minimal victory approach).  
Sometimes minimalism is better; sometimes it only 
delays the implementation.  Requirements analysis 
first, of course.

I agree that having only one definition from an 
agency that by the illusion of authority is 
promoted is bad.  Multiple definitions which 
do not enable a process to remain coherent is 
also bad.   Therefore, the engineers have to 
actually ask the users which they prefer. (Note, 
I didn't say, ask the managers.)  My position is 
that these multiple means do not compete but 
could be construed as such depending on the 
means used to choose the means.  Semantics 
is a means to choose among means.  I think 
that is why some are starting to look very 
seriously at concept modeling as a layer over 
XML modeling for large systems where by large 
systems, I mean, multiple authoritative scopes 
of control.

Len 
http://www.mp3.com/LenBullard

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


-----Original Message-----
From: Bob Kline [mailto:bkline@rksystems.com]

The problem with separating out context rules into the application is
that we would undermine one of the primary benefits of the current
project to replace the customer's legacy document creation/maintenance
system, in which it is impossible to modify document structures or
business rules without dragging in a programmer.

The problem with separating out context rules into a separate document
(such as Schematron) is the standard one of keeping modifications to
separate specifications of the document structures in sync.

We could ignore W3C's schema syntax altogether and simply adopt one of
the competing models (e.g., Schematron or RELAX) but this path incurs
the risk of much lower levels of support from third-party toolsets.

It may well be true that for some projects separating out different
components of document constraints will be the most appropriate
approach.  It is unfortunate, however, that the spec most likely to
attract third-party support (by virtue of its sponsorship by W3C)
assumes that this is the *only* valid approach.