Lotsa laughs

[Steven R. Newcomb]

[Didier:]

> The DTD problem and document validation is only part of the problem
> and we are actually facing a lot of issues to be resolved in order
> that all parties recognize that a transaction is valid. XML.org,
> resetta.net, eco and others try to create conventions on which all
> parties will have to agree. One thing remain, a DTD is
> insufficient. We also need: a) reliable repositories and document
> specification conventions and references

Sounds like the role of xml.org to me.

> b) way to tell that this transaction is really from the one who
> claim being the transaction initiator (The community have to agree
> on an authentication method)

Yup.  Actually, we need an engine for this purpose, and, even more
important, 

  * the ability to plug that engine into our doc processing
    applications, and

  * the ability to inherit the information architecture that that
    engine understands into any other information architecture.

Sounds like the proper role of the grove paradigm, with property sets
for inherited architectures.  XML Schema is getting there, but it's
not quite there yet.

> c) We won't have a simple universe, so there will be more than one
> document specification for the same kind of transaction. So we'll
> need official translation form a transaction format to an other and
> repository where these rule are stored.

What's really needed is a formalized property set for each information
set that is conveyable by each information architecture.  With such
property sets, arbitrary conversions become possible, and hooking each
architecture's engine to each other architecture's engine becomes a
piece of cake.  Yes, we certainly need a repository for such property
sets.  Sounds like the role of xml.org to me.

> d) And finally interpreters or parsers+interpreters that can
> validate a document and interface with back ends ERP.

You're describing architecture-specific engines for creating
property-set conforming groves from interchangable resources.  Groves
are, by definition, ready to connect to ERP or any other kind of
application.

> Actually DTD is insufficient to provide all necessary information,

Right.  You need not only an interchange specification, but also the
abstract information set.  That's what a property set is supposed to
be.  There is a lot of confusion out there.  The simple fact is that
we need BOTH an interchange spec AND an abstract information spec in
order to efficiently interchange any particular kind of information
in an application-neutral and vendor-neutral fashion.

> Schema is not yet a recommendation. Time is clicking and corporation
> want to take position in this new rat race.  So...I am not so sure
> that only DTD will resolve the problem especially when you
> dynamically compose a new XML document from XML document (EX: a
> transaction that includes a request for a catalog and a purchase
> order - two different documents merged into one). The DTD would have
> to be dynamically created as the document is.

And that's a completely and easily supported scenario, given
inheritable architectures, property sets, and groves.

-Steve

--
Steven R. Newcomb, President, TechnoTeacher, Inc.
srn at techno.com  http://www.techno.com  ftp.techno.com

voice: +1 972 231 4098 (at ISOGEN: +1 214 953 0004 x137)
fax    +1 972 994 0087 (at ISOGEN: +1 214 953 3152)

3615 Tanner Lane
Richardson, Texas 75082-2618 USA

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)