[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Are we losing out because of grammars?

  • From: Rick Jelliffe <ricko@a...>
  • To: xml-dev@l...
  • Date: Thu, 01 Feb 2001 15:12:28 +0800

study support and grammars
From: Ken North <ken_north@c...>

> Using application code to enforce rules, instead of declaring constraints
> that are managed by the container (database), leads to versioning
> In the XML world, we can now exploit types and constraints, but one
> is whether developers will learn from the SQL experience, i.e.,
> 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.

Rick Jelliffe


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.

Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.