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

LC-178 clarify!

From: C. M. Sperberg-McQueen <cmsmcq@acm.org>
Date: Thu, 05 Oct 2000 22:47:09 -0600
Message-Id: <>
To: Murray Altheim <altheim@eng.sun.com>
Cc: W3C XML Schema Comments list <www-xml-schema-comments@w3.org>
Dear Murray:

The W3C XML Schema Working Group has spent the last several months
working through the comments received from the public on the last-call
draft of the XML Schema specification.  We thank you for the comments
you made on our specification during our last-call comment period, and
want to make sure you know that all comments received during the
last-call comment period have been recorded in our last-call issues
list (http://www.w3.org/2000/05/12-xmlschema-lcissues).

Among other issues, you raised the point registered as issue LC-178,
which suggests that the WG work to simplify the prose of the
specification, to remove some of the abstraction, provide a glossary,
add short examples, and simplify some features of the spec.

(In passing, I should note that I am a little puzzled by some of what
you say in the passage of your review quoted under this issue number
in the issues list.  The normative text of ISO 8879 has no examples at
all -- there are examples in the non-normative appendices, but none at
all, and no cross-references either, in the body of the document.  I
agree with you fervently that having lots of short examples is a big
help -- but I learned that fact by the years it took me to learn
ISO 8879.)

The WG has considered at some length this issue and others which
similarly suggest ways to simplify the specification and render it
more readable.  The problem is not susceptible to a simple solution,
nor your proposals and those of other commentators to a simple yes/no
answer.  We have made some editorial changes, and are exploring more,
and hope to use the candidate recommendation period to continue
improving the expository prose in the spec.  We are experimenting with
changing the display of information about XML schema components and
about the mapping from the transfer syntax into the abstract
components.  We are exploring the possibility of changing the sequence
of exposition so that the concrete transfer syntax would be introduced
first, then the abstract components; we are also experimenting with a
reorganization of the structures spec which would treat both the
abstract level and the transfer-syntax of each component in a single
section (effectively merging what are now chapters 3 and 4).  And --
this is not quite what you asked for, but it's related -- a task force
is now engaged in preparing a fully formal treatment of XML Schema in
a logical notation, which may make it possible for some of the prose
to become simpler and less excruciatingly precise.

We have decided to move forward with a request for publication as a
candidate recommendation in part because publication as a CR is a
useful signal to implementors that the spec is stable enough to
implement, and it is the deep conviction of at least some in the WG
(myself included) that having implementations around to allow one
to try things out and see whether they work will contribute far more
to the accessibility of XML Schema than would any amount of further
editorial reworking.

Regarding your other suggestion, the WG has not been able to see its
way clear to eliminating the abstract level of schema description
which has clearly caused a fair amount of trouble to you and some
other readers, nor to removing all of the functionality you recommend
(as have some others) be saved for a later version of XML Schema.

The abstract component level of description is important to a large
proportion of the WG because it helps us avoid the trap into which
SGML and XML have occasionally fallen.  In XML, an element, formally,
is nothing but a string of characters which satisfies a particular
grammar.  There is no explicit notion in the XML spec of the tree
structure which many feel is crucial to the appeal of SGML and XML,
and it is possible to argue with a straight face that if one uses a
DOM interface to build a document in memory, that document is not XML
-- not because it's not a legal tree structure, or because it doesn't
meet the validity constraints of a given DTD, but because it doesn't
have angle brackets in it.  This phenomenon is troubling enough that
the XML Schema WG is determined to avoid falling into a similar trap.
By defining the abstract layer explicitly, and defining conformance in
terms of it, we make explicit the fact that the essential
characteristics of a schema, and of validation, are not tied to a
particular physical or logical representation, and that a schema may
be hard-coded into a piece of software (e.g. into a set of Java
classes or into a yacc-generated parser) without for that reason
ceasing to be, in the salient sense of the word, a schema.  This does
mean that conformance to the XML Schema may take somewhat more various
forms than, say, conformance to ISO 8879.  But it also means that
conformance is now described at what seems to the WG a more useful
level of abstraction.

As to the functionality, there is not much I can say.  The WG did have
a small and (for a while) vocal minority urging it to issue a version
1.0 of XML Schema with less functionality.  ("DTDs plus datatypes" was
a popular slogan for a while.)  The large majority of the WG, however,
consists of representatives of communities for whom "DTDs plus
namespaces" does not represent a useful enough advance over DTDs to be
worth the trouble.  And so we have functionality which is a
significant advance over that provided by DTDs.  The W3C process
requires consensus first of all within the WG, that is among those
organizations and individuals willing to make the time investment
necessary to develop a specification.  And the result of that process
is the functionality now in the XML Schema spec.

For what it's worth, I think that some readers (perhaps including
yourself) have gotten a false impression about the origin of some of
the functionality in the spec.  The functionality that goes beyond
DTDs, I sometimes hear, has been added to support interchange of SQL
and other DBMS data and so on, and has no relevance for documents and
document-oriented markup languages.  This is true for some of that
functionality.  But much of the functionality provided by XML Schema
that goes beyond what is offered by DTDs is there, in the first
instance, because those of us who have spent the last ten years
writing DTDs for documents had a well-developed sense of various kinds
of extra functionality that would be useful, from datatypes and
regular-expression pattern constraints on simple types to local
element-type definitions and better wildcards.  That many of the needs
of document-related work coincide with those of database-oriented work
simply goes to underscore the importance of Murata Makoto's
observation that XML can and must serve both DBMS-style data and
document-style data, and that its primary interest lies in its ability
to support both using the same set of facilities.

It would be helpful to us to know whether you are satisfied with the
decision taken by the WG on this issue, or wish your dissent from the
WG's decision to be recorded for consideration by the Director of
the W3C.

with best regards,

-C. M. Sperberg-McQueen
  World Wide Web Consortium
  Co-chair, W3C XML Schema WG
Received on Thursday, 5 October 2000 19:03:57 UTC

This archive was generated by hypermail 2.3.1 : Friday, 13 July 2018 09:02:52 UTC