Re: W3C Schema Work Machinations.

David,

I think you will be pleasantly surprised with the agreement with those in
industry who are with you on this topic.  When I talk with people at the
various initiative meetings and conferences, the discussion today goes very
much the same way as you have expressed.  Everyone realizes that what gets
published as a recommendation today is what we will be living with for many
years to come; I don't expect there will be any updates on this
specification for awhile.

There are really two distinct pulls here - document-centric (closed system)
desires vs. that of data-centric (manipulating and exchanging with and
between applications) requirements.

-  If I were building an internal system I most certainly want all the bells
and whistles we can possibly invent to be included in the specification.

-  But on the other hand, exchanging information with another division or
trading partner, I want capability to have full constraint mechanisms,
common tag reference mechanisms, versioning, discovery, XML/edi templates,
etc. (items which have been documented and discussed in the various meetings
which you list in your email).  For a global exchange mechanism, we can't
expect our complete set of trading partners to respond to all of the current
draft specification in a predicable manner.

In your opinion, does it make sense to have a minimium 'base' XML Schema and
then have two extensions; document & data?   Or are your envisioning more
with 'a hierarchy of representational levels'?

As to the 'three month timeframe', I think the members of the W3C should
decide the schedule.  This hierarchy approach should allow the working group
to concentrate on what constitutes the 'base', and consider what best makes
sense for the other 'representational levels'.  As you suggest, this would
give us more time to work and prove the extensions before going to
recommendation status following a period of time after we can a chance to
begin implementation using the base recommendation.

This approach I think would be accepted with open arms in the community.
For a recommendation with a larger scope and without proper constraints for
exchange would force a subset of the specification to be used in industry
and will keep the various non-interoperable implementions on other critical
items.  IMHO:  The W3C decision here could either save or cost industry
billions of dollars over the next few years.

- Bruce




----- Original Message -----
From: "David RR Webber" <Gnosis_@compuserve.com>
To: "W3C Schema Comments" <www-xml-schema-comments@w3.org>; "ebXML
Architecture" <ebxml-architecture@lists.oasis-open.org>
Cc: "The XML/EDI Group" <xmledi-list@lists.bizserve.com>
Sent: Tuesday, April 11, 2000 11:34 AM
Subject: Re: W3C Schema Work Machinations.


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.

Received on Wednesday, 12 April 2000 16:06:39 UTC