[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: What is the advantage of RELAX in comparison to Schemas?
- From: "Bullard, Claude L (Len)" <email@example.com>
- To: Bob Kline <firstname.lastname@example.org>
- Date: Tue, 30 Jan 2001 09:43:25 -0600
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. ;-)
Ekam sat.h, Vipraah bahudhaa vadanti.
Daamyata. Datta. Dayadhvam.h
From: Bob Kline [mailto:email@example.com]
Sent: Tuesday, January 30, 2001 9:52 AM
To: Bullard, Claude L (Len)
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.