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

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

I think yes we agree.  Then would you also agree we are 
back to the problem of what a namespace signifies? 

That is, if we must live with the XML Schema 
as not having context-aware contraints, in many 
cases dereferencing the namespace URI/URL must 
return information (eg, a RDDL) that enables 
the interpreter of the document to locate 
all of the constraints explicitly defined 
by the sender as needed for interpretation?  

In that case, I still prefer the separation 
to enable the receiver to toss rules not 
needed if not needed.  That is something 
similar to an old old issue of who gets 
to decide what a document means or renders 
as:  the author or the reader.  Definitely 
hemeneutics.  Get out the Wittgenstein. ;-)

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]
Sent: Tuesday, January 30, 2001 9:52 AM
To: Bullard, Claude L (Len)
Cc: xml-dev@lists.xml.org
Subject: RE: What is the advantage of RELAX in comparison to Schemas?


On Tue, 30 Jan 2001, Bullard, Claude L (Len) wrote:

> 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).

We are largely in agreement, it seems to me.  You recognize that in some
cases (our project would be an example, we believe) the "monolithic"
approach is most appropriate.  I agree that for other projects layering
of constraint specifications is called for.  Unfortunately, even for
those cases, if W3C's schema mechanism is adopted for the core
agreement, the boundaries between the layers are driven not by the
requirements of the project (it may well be that "element E can only
contain children C when E is part of parent P" is one of the core
components universally agreed upon for a given document type), nor by
distinctions between simplicity and complexity (it would be amusing to
see an attempt to demonstrate that W3C's schema spec supports only
"simple" constraints), but by the decision to omit support for the
common requirement of context-aware content models.

-- 
Bob Kline
mailto:bkline@rksystems.com
http://www.rksystems.com