Re: W3C Schema Work Machinations.

[David RR Webber <Gnosis_@compuserve.com>]

Message text written by Alan Kotok
>
Speaking of XML Schema, the last-call working draft documents are found at 
these addresses ...

XML Schema Part 0: Primer
http://www.w3.org/TR/2000/WD-xmlschema-0-20000407/
XML Schema Part 1: Structures
http://www.w3.org/TR/2000/WD-xmlschema-1-20000407/
XML Schema Part 2: Datatypes
http://www.w3.org/TR/2000/WD-xmlschema-2-20000407/
<

>>> From the W3C Web site >>>
Although the Working Group does not anticipate further changes to the
functionality described here,
this is still a working draft, subject to change. The present version
should be implemented only by
those interested in providing a check on its design or by those preparing
for an implementation of
the Candidate Recommendation. The Schema WG will not allow early
implementation to constrain
its ability to make changes to this specification prior to final release. 
<<<<<<<<<<<<<<<<<<<<<<<<<<

This is legal hogwash at its finest!  Translation: this will not change,
but it might, and anyway 
we're not responsible for anything.

Put another way - total confusion reigns at this point.   I've been
consistently saying since day one
that the current W3C Schema work is fundamentally flawed and does not
provide a functional 
system that can support broad eBusiness interchanges in the same way that
X12 and EDIFACT 
have provided for EDI.   There are too many omissions, too many
shortcomings and not enough
regard to basic usability.   

This is not to attach blame, the current spec's answer the mail, problem is
- its the wrong mail!   
The requirements fail to encompass what is now transpiring with ebXML, 
eCo and eSpeak to name some.  Then a simple review of industry initiatives
such as FIXML, 
wfmXML, RosettaNet, show the need for eBusiness directed mechanisms that
are just not being
addressed.    Again, the requirements for Schema were written nearly two
years ago - its time
to address this and revisit the requirements in the context of 2000/2001
and eBusiness needs.

All this is documented at  http://www.bizcodes.org/eDTD/xml-eDTDWP.htm

In amongst all this we have individual people doing good work - like the
Xinclude work -
that shows exactly the sort of items that should be included into the core
of Schema - not
side notes or after thoughts.

The other insiduous factor here is that short-term vendor aims are
overriding commonsense
and good standards development practice.   Certain vendors perceive that
they 'need' any 
kind of Schema NOW!   Various reasons - main one being that Microsoft and
BizTalk are on
the ropes - so let's kick 'em while they are down - next one being that
certain vendors are
signing huge deals to implement XML systems for Fortune 100 clients - so
let's build today
and fix it tomorrow.  Alright I've said the unspeakable.  Now let's get
back to where we 
should be going with this as a real standards development process.

1) Moritorium of 3 months to allow Schema Specifications to be re-visited,
particularly in the
     context of ebXML technical requirements.

2) 3 Tier syntax strategy to be adopted that allows hierarchy of
representational levels -
         abstract a la RELAX
         syntax neutral 
         business functional - ebXML

3) Field testing for 6 months PRIOR to formal adoption, with selection of
industry groups 
     providing evaluations, not just a set of vendors.

4) Interoperability test-suite development to ensure consistency.

Of course there are issues with this - but nothing that cannot be resolved
by setting
working parameters and putting together a cross-management group to oversee
the technical work.  We have plenty of precedence for this with efforts
like RosettaNet
and the standards groups X12, HL7, EDIFACT, et al.    Yes this takes time,
but this is
one instance when that's exactly the path we should be taking now.

I'd rather have an objective Schema system that has been developed with 
broad involvement, rather than spending the next several years fixing up an
inadequate system.  

History teaches us that EDIFACT's semantics are much cleaner than X12's
because X12 is a hodgepodge that evolved in an adhoc fashion.   Right now
we are looking at history repeating itself - and ebXML is our one bright
hope 
to ensure that two years from now we're not looking at a dozen variants of
XML/edi - all of which are not interoperable.

Thanks, DW.