Re: Are we losing out because of grammars?

[Rick Jelliffe <ricko@allette.com.au>]

From: Ken North <ken_north@compuserve.com>

> Using application code to enforce rules, instead of declaring constraints
> that are managed by the container (database), leads to versioning
problems.
> In the XML world, we can now exploit types and constraints, but one
question
> is whether developers will learn from the SQL experience, i.e.,
declarative,
> container-managed logic solves some of the proliferation/fragmentation
> problems that occur with ad hoc application logic.

When you say "container (database)" I am not sure if you mean big documents
with full markup or centralized DBMSs.  If the latter, then I wonder
whether, to some extent, people like XML because it holds the hope of
escaping from centralized DBMSs; in other words, the important SQL
experience has to be judged with different architectures in mind, in
particular for data delivery not just data querying. For example, what is
the schema for routable documents which get information added as they pass
through different stages (i.e. orders, etc.): is it just the union of any
data that is added at any time?

Underlying Murata-san's RELAX seems to be that we should start from
desirable properties that web documents need: lightweightedness, functioning
even if the schema goes offline (hence no PSVI) and modularity.   I think
underneath James Clark's TREX is that we can support plurality if we have a
powerful-enough low-level schema language into which others can be well
translated.  I think underlying W3C XML Schemas is that a certain level of
features and monolithicity is appropriate (though perhaps regrettable)
because of the need to support a comprehensive set of tasks and to make sure
that there are no subset processors (validity should always mean validity);
however the processors are monolithic but the schemas are fragmented by
namespace. Underlying Schematron is that we need to model the strong
(cohesive) directed relationships in a dataset and ignore the weak ones,
that constraints vary through a document's life cycle, and that lists of
natural language propositions can be clearer than grammars.

So there should be a class of standard constraint languages which are not
platform-API-dependent (e.g., not .NET code, not Java code, not Python) but
lightweight-enough to get widely deployed and which cater to stakeholder
group's particular requirements, as well as schemas for DBMSs.  A trouble
with the centralized view seems to me that it always will focus attention on
issues of "efficient storage and query" which are somewhat (sometimes
utterly?) extraneous to the needs of data on-the-wire.

Cheers
Rick Jelliffe