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

Re: W3C Schema Work Machinations.

From: David RR Webber <Gnosis_@compuserve.com>
Date: Wed, 12 Apr 2000 16:45:03 -0400
To: "Bruce Peat" <BPeat@eProcessSolutions.com>
Cc: "The XML/EDI Group" <xmledi-list@lists.bizserve.com>, "ebXML Architecture" <ebxml-architecture@lists.oasis-open.org>, "W3C Schema Comments" <www-xml-schema-comments@w3.org>
Message-ID: <200004121645_MC2-A0F2-15F5@compuserve.com>

Your laser vision is functioning with its usual high level of perception.

Here is indeed the heart of this whole matter.  How to create mechanisms
that support simple inituitive usage without a high learning curve on the 
front-end, while also providing a rich depth and breadth for those partners
who need extended functionality.

I believe we have demonstrated some significant capabilities in this area
with eDTD and Bizcodes, and Martin Bryan's Syntax Neutral paper.  Right now
the need is to blend these and pick some approaches that can lead the way

Just recently I did some work on a power industry billing schema.   When
sit down and create real world examples all these issues are immediately
apparent and central - how do you craft syntax that is simple to use,
(a key feature of systems like Prolog, but absent in C++), and
interoperable and
with a simple adoption curve from existing database models?

I don't think the issue is one of documents v data.  The power billing
schema had a high
degree of presentational content in the fancy printed format.  The future
also tells
us that the document will be the data as systems transition to XML as the
format.  BUT the issue is one of business information v open lightly
document content.  That will change - because a document must become
centric.  Anyway - this said - what we're looking at here is that by
getting it right from
the data perspective, the documents definitions will work fine as a

You can see this today already in products like XMetal which have a very
degree of compliance and structural validation checking in them, compared
say IE5.0 which is wildly lax.  So documents with data created in XMetal
are going
to be much more 'automated-processing' friendly by definition.   Hope this
all makes

Your last point then emphasizes this even more - can I go 'round-trip' -
edit in
XMetal, open in MS Word or IE5.0?  Answer right now is an emphatic NO!  Not
unless you spend alot of programming time yourself fixing holes.   And this
just with the "simple" DTD and XML V1.0 spec's!!!  Clearly, we have to
very well here where the minefield is, and how to steer a safe path to the 
secure intuitive future we all seek.

Thanks, DW.
Message text written by "Bruce Peat"
In your opinion, does it make sense to have a minimium 'base' XML Schema
then have two extensions; document & data?   Or are your envisioning more
with 'a hierarchy of representational levels'?

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

Received on Wednesday, 12 April 2000 16:46:36 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:08:47 UTC