Bruce,
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
forward.
Just recently I did some work on a power industry billing schema. When
you
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,
self-corrective,
(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
base
format. BUT the issue is one of business information v open lightly
structured
document content. That will change - because a document must become
information
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
side-effect.
You can see this today already in products like XMetal which have a very
high
degree of compliance and structural validation checking in them, compared
to
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
sense!?
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
is
just with the "simple" DTD and XML V1.0 spec's!!! Clearly, we have to
understand
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"
> SNIP
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'?
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
<
==========================================
XML/EDI Group members-only discussion list
Homepage = http://www.xmledi.org
Brought to you by: Online Technologies Corporation
Home of BizServe - www.bizserve.com
TO UNSUBSCRIBE: Send email to <[EMAIL PROTECTED]>
Leave the subject blank, and
In the body of the message, enter ONLY: unsubscribe
Questions/requests should be sent to: [EMAIL PROTECTED]
To join the XML/EDI Group complete the form located at:
http://www.geocities.com/WallStreet/Floor/5815/mail1.htm
