OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] Who can implement W3C XML Schema ?

[ Lists Home | Date Index | Thread Index ]

From: "Jonathan Robie" <jonathan.robie@softwareag.com>

> Does anybody have real data on the market penetration of XML Schema? I 
> think that vendor support for XML Schema is clear, but if Adam is right, 
> that's irrelevant. Vendors seem to believe that people are actually using 
> XML Schema, too. Are they right? Do we have real evidence on this question?

Which market?  Could we guess 

   Publishing market: almost 0% uptake
   Interprocess-communications-using market: medium uptake
   DBMS-to-middleware market: high uptake

because XML Schemas is little value for publishing (because people need
entities, therefore they cannot throw the DTDs away, therefore XML Schemas
being so monolothic creates a duplication of effort for not much reward.
However, people who expect data definitions and database-style
datatyping and so-called schema management tools will find XML Schemas
more congenial.

Most people who slag off XML Schemas do so because one size cannot
fit all.  The initial step has to be figuring out which schema language
or processing combination is appropriate for each sector.  I expect
that as publishing-messaging XML bifurcates from database-XML
that it will settle down to DSDL (e.g. RELAX NG + Schematron
+ localizable datatypes) for the former and XML Schemas (+ SAF
and embedded Schematron) for the latter.  

XML Schemas should have been modular: it was not because of the
decision that every XML Schema processor should return the
same ultimate valid/invalid distinction on a document. This logically
forbids subsets, which is great promotor of modularity. The irony is
that this lack of modularity probably has resulted in the opposite result:
XML Schemas implementations are so poor in agreement.

I think it would be really useful for the XML Schema WG to, rather than
rewrite part 1, split parts 1 and 2 into six or eight parts:
  1) Schema construction and namespace handling
  2) Type derivation and labelling
  3) Structures
  4) Keys and uniqueness
  5) Primitive datatypes and facets
  6) Datatype derivation and built-in derived types
  7) Schema Adjuct Framework
  8) Embedded Schematron Schemas

which would allow greater modularity, let readers and implementers concentrate
and advertise conformance on different parts, and fit in with ISO DSDL, for
users who, say, want to use RELAX NG with XML Schemas primitive datatypes.

The verbal difficulty of the spec is one thing; but the difficulty of each paragraph
is multiplied by the lack of modularity in the subject of the spec. 

Rick Jelliffe


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS