xml-dev - RE: W3C XML Schema moves forward

[johns@syscore.com (John F. Schlesinger)]

Has anyone created meta-models (in UML, MOF or any other notation) of the
XML Schema (or XDR) or XSLT specifications?

It looks as though the XML Schema of Schemas could be a start for a
meta-model for XML messages or documents.

I am looking to try and store XML schemas and transforms in a simple
repository for a client and it would be good to use a meta-model that all on
this list could (or have) agree to.

This repository would enable us to answer questions like: what would be the
impact of changing a message (by tracing the XSLT transforms forward); what
is the meaning of this message (by tracing the XSLT transforms backward);
and what data is available in messages.

Yours,
John F Schlesinger
SysCore Solutions
212 619 5200 x 219
917 886 5895 Mobile

-----Original Message-----
From: ricko@mail.geotempo.com [mailto:ricko@mail.geotempo.com]On Behalf
Of Rick JELLIFFE
Sent: Thursday, September 07, 2000 10:11 AM
To: xml-dev@lists.xml.org
Subject: Re: W3C XML Schema moves forward


Robin Cover wrote:
>
> Questions have been raised episodically about the usability of W3C's
> 'XML Schema' formalism (http://www.w3.org/TR/xmlschema-1/): does it
> attempt too much?, is the spec hard to understand?, is the notation
> excessively verbose?, etc.  Despite these doubts, the WD specification
> seems to make sense to a growing number of developers.  I note
> (anecdotically) that W3C XML Schema (.xsd) is used as the principal
> meta-level specification in two important projects, announced
> recently:
>
> "DIG35: Metadata Standard for Digital Images"
>   http://www.oasis-open.org/cover/dig35.html
>
> "Universal Description, Discovery, and Integration (UDDI)"
>   http://www.oasis-open.org/cover/uddi.html
>
> These are not lightweight or trivial XML applications.

The other factor at play is that the W3C XML Schema WG has
tried (through the last call draft procedure, e.g.) to listen
to comments that the spec is too hard, that the notation is
excessively verbose, and even that it attempts too much
(in some pet area) or too much (in some other pet area).

XML Schemas is an evolving, and IMHO improving, target.

I think the upcoming version will be much better received than
the previous drafts: it has benefited from the extensive
comments in exactly the kinds of areas Robin mentions.
I have been very impressed by recent improvements, watching from
afar: the editors are doing great jobs.

However, *before* a spec is finalized *is* the appropriate time
to pick nits, be they large or small!  If an issue is important
for a user, it is fair game to comment about it and
try to influence XML Schemas in an improved direction.  Just as with
the last round, I encourage XML-DEV-ers to look critically
and thoroughly at the upcoming specs: do they meet your needs?
are they incomplete in any significant way that might allow
vendors to trap you to their products?   Can you do simple
things simply?   Can you use the elements and attributes and
values in the ways you think are natural (is it methodology-free
enough)?  When I extract some data from a schema-ed document,
can I do enough with it?  What features in particular are
definitely "too much"?  Are the datatypes complete (should
money be a built-in datatype, for example)?

In the Candidate Release phase, it is almost too late to make
general "I like this" or "I don't need that" comments: instead,
I think the focus is more on getting implementation feedback:
"this part of the spec is ambiguious", "this is good enough
for now", "this part of the spec was hard to implement",
"I tried to convert my DTD to XML Schemas and had difficulty
because of such-and-such a reason", "the relation to
W3C technology XXX is unclear or troublesome", etc.

Finally, I don't think it is surprising that the people
who have financed XML Schema's development should be keen
to use it (uddi.org seems to have many of the same key
players as are in the W3C). I don't think anyone is claiming
that the recent XML Schema drafts are useless. But that does
not really speak about whether XML Schemas attempts "too much":
that is an unresolvable question because XML has expanded
to be more than just the simple data-interchange format. Now it is
a Nutty Professor II -style family of technologies that
are being used to model/process the databases as well as the
reports.

(I think that was a key issue, actually: should
XML Schemas have limited itself to only small documents
on single topics {i.e., reports) or must it provide enough
metadata decorations of the infoset to provide XQuery with
the basis it needs?  Indeed, is XQuery really XML at all, if it is
concerned with querying of large databases rather than
data transfer?  A document can be a database, but in moving
to support databases, do we lose the plot and the focus on
interchange?  It is a pity that this issue has never really,
to my knowledge, been discussed much publically--it has just
sort-of happened to XML, and reactions like SML are hardly surprising.)

Finally, I should point out that it is perfectly possible to
derive your own restricted schema language based on XML Schemas,
and adopt that in your organization, if full XML Schemas is too
big. This is no different from adopting a particular profile
of XML (as XML itself is a profile of SGML).  You could, for
example, decide that you will only make use of structural
features that have direct equivalents in DTDs. Or not to
derive your own datatypes.  You could even make up your
own tools for these--such tools would not be conforming
XML Schema tools, but they might be useful.  Just because
XML Schemas provides a feature does not mean one has to
use it!

Rick Jelliffe