[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)" <firstname.lastname@example.org>
- To: Bob Kline <email@example.com>
- Date: Tue, 30 Jan 2001 09:03:04 -0600
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
Ekam sat.h, Vipraah bahudhaa vadanti.
Daamyata. Datta. Dayadhvam.h
From: Bob Kline [mailto:firstname.lastname@example.org]
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.