W3C home > Mailing lists > Public > www-xml-schema-comments@w3.org > January to March 2000

Re: COMPLEXITY BIG ISSUE & W3C Schema

From: David RR Webber <Gnosis_@compuserve.com>
Date: Sun, 5 Mar 2000 12:21:28 -0500
To: W3C Schema Comments <www-xml-schema-comments@w3.org>
Cc: "[unknown]" <ebXML-Architecture@lists.oasis-open.org>, "[unknown]" <ebXML-Transport@lists.oasis-open.org>
Message-ID: <200003051221_MC2-9BD5-5743@compuserve.com>

Looking into the W3C Schema work - here is the heart
of the issues.

On the one hand the W3C Schema Requirements state:

3. Usage Scenarios

The following usage scenarios describe XML applications that should
benefit from XML schemas.  They represent a wide range of activities and
needs that are representative of the problem space to be addressed.
They are intended to be used during the development of XML schemas as
design cases that should be reviewed when critical decisions are made.
These usage scenarios should also prove useful in helping non-members of
the XML Schema Working Group understand the intent and goals of the
project.

Electronic commerce transaction processing.

Libraries of schemas define business transactions within markets and
between parties.  A schema-aware processor is used to validate a
business document, and to provide access to its information set.

Supervisory control and data acquisition.

The management and use of network devices involves the exchange of data
and control messages.  Schemas can be used by a server to ensure
outgoing message validity, or by the client to allow it to determine
what part of a message it understands.  In multi-vendor environment,
discriminates data governed by different schemas (industry-standard,
vendor-specific) and know when it is safe to ignore information not
understood and when an error should be raised instead; provide
transparency control.  Applications include media devices, security
systems, plant automation, process control.

Traditional document authoring/editing governed by schema constraints.

One important class of application uses a schema definition to guide an
author in the development of documents.  A simple example might be a
memo, whereas a more sophisticated example is the technical service
manuals for a wide-body intercontinental aircraft.  The application can
ensure that the author always knows whether to enter a date or a
part-number, and might even ensure that the data entered is valid.

Use schema to help query formulation and optimization.

A query interface inspect XML schemas to guide a user in the formulation
of queries.  Any given database can emit a schema of itself to inform
other systems what counts as legitimate and useful queries.

Open and uniform transfer of data between applications, including databases

XML has become a widely used format for encoding data (including
metadata and control data) for exchange between loosely coupled
applications.  Such exchange is currently hampered by the difficulty of
fully describing the exchange data model in terms of XML DTDs; exchange
data model versioning issues further complicate such interactions.  When
the exchange data model is represented by the more expressive XML Schema
definitions, the task of mapping the exchange data model to and from
application internal data models will be simplified.

Metadata Interchange

There is growing interest in the interchange of metadata (especially for
databases) and in the use of metadata registries to facilitate
interoperability of database design, DBMS, query, user interface, data
warehousing, and report generation tools.  Examples include ISO 11179
and ANSI X3.285 data registry standards, and OMG's proposed XMI
standard.


============================================================

but then the details to meet these the requirements are stated
below, to which my comments are:

Notice that NOWHERE is anything core that pertains to
B2B mentioned - version control, avoiding information
structure clashes, interoperablity with legacy EDI,
support for and enablement of repositories /
interoperability between schema semantics, human
readable and understandable models, consistent
behaviour guaranteed of parsers by ensuring simple
constructs and ability to select layers of features,
just for starters!

(Most troubling is statements on Metadata and ISO11179, XMI,
 databases, et al in the usage scenarios .  
 This seems to completely miss the point, but that's a side issue;
  even though an important one!)

So here we have a proposal that purports to be business
focused - but is totally off base on the business
requirements.  My recommendation is to reject the current
W3C syntax until the requirements more adequately reflect
true B2B and ebXML needs.  To facilitate this may well require
a joint technical working group, or at least two technical working
groups with formal liaison established.....  this issue was already 
raised in Orlando at the Steering Committee and the need appears
to be as yet unfulfilled.

DW.

[clip]
===  W3C  Schema Requirements ============================

5. Requirements

Structural requirements

The XML schema language must define:

mechanisms for constraining document structure (namespaces, elements,
attributes) and content (datatypes, entities, notations);

mechanisms to enable inheritance for element, attribute, and datatype
definitions;

mechanism for URI reference to standard semantic understanding of a
construct;

mechanism for embedded documentation;

mechanism for application-specific constraints and descriptions;

mechanisms for addressing the evolution of schemata;

mechanisms to enable integration of structural schemas with primitive data
types.

Datatype requirements

The XML schema language must:

provide for primitive data typing, including byte, date, integer,
sequence, SQL & Java primitive data types, etc.;

define a type system that is adequate for import/export from database
systems (e.g., relational, object, OLAP);

distinguish requirements relating to lexical data representation vs.
those governing an underlying information set;

allow creation of user-defined datatypes, such as datatypes that are
derived from existing datatypes and which may constrain certain of its
properties (e.g., range, precision, length, mask).

Conformance

The XML schema language must:

describe the responsibilities of conforming processors;
define the relationship between schemas and XML documents;
define the relationship between schema validity and XML validity;
define the relationship between schemas and XML DTDs, and their information
sets;
define the relationship among schemas, namespaces, and validity;
define a useful XML schema for XML schemas;
Received on Sunday, 5 March 2000 12:22:19 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 6 December 2009 18:12:46 GMT