Lotsa laughs

Wed May 26 22:56:22 BST 1999

Hi Lisa,

--------------------
Lisa said:
Said another way:  Since a currently-implemented, XML v. 1.0-compliant
validating parser would not be able to use a BizTalk schema to validate
documents (since BizTalk schemas use syntax that is not specified in the
version 1.0 Recommendation), wouldn't such an existing XML v.
1.0-compliant parser implementation "break" as a result, unless its
creators had also implemented whatever additional, non-standard (and
therefore proprietary) software that BizTalk requires?

Didier say:
After reading a second time the documents, it is not said if a DTD is
provided or not. If no DTDs are provided, a validating parser won't work.
But at this stage we do not know if biztalk will or will not provide DTDs
for each type of documents. However, from the video presentation it seems
that all document type are based on former work like for instance HL7 (which
has a DTD). Because they add a document envelope in the form of a <route>
and <body> fragments, they could provide a modified DTD for each new
document. But this brings a new problem for dynamically created documents
like it could be possible with e-commerce documents. The final document is
composed of an envelope and an other document contained in it (EX: the
envelope, a catalog request and a purchase order). The resultant document
being a XML document. When a XML document is composed of other XML
documents, how can we then get a DTD for the resultant document? Do schemas
will resolve the problem? A story to follow....
----------------

----------------
Lisa said:
Wouldn't a more "compliant" BizTalk strategy be to have BizTalk using
DTDs for now, which could then upgraded to schemas (when everyone else
upgrades to schemas) as soon as a proper XML Schema Recommendation
becomes available.  That way, developers wouldn't have to choose one
schema syntax over another (and at the expense of being incompatible
with everything else) because the schema syntaxes would all be
compatible - with each other AND early implementations that used the
BizTalk DTDs for validation.

Didier say:
This could be a temporary solution indeed. I guess from what I saw that it
could be possible to create a DTD that includes the envelope and the
transaction document. At least this DTD could be posted to XML.org. But this
does not resolve the problem of composing a document with several
transactions in it (a transaction being itself a XML document). Or, the DTD
should include all possible transactions ( a big jumbo DTD :-)
--------------

--------------
Lisa said:
Also, on a less technical, more practical note: Why would anyone want to
put time into using the BizTalk schemas if they know are going to just
have to redo them again when Microsoft, in good faith, changes the
BizTalk schemas over to the W3C's Schema syntax?   Or the reverse of
that would be - why would a microsoft-centric developer want to ever
bbother changing over to the proper W3C syntax if they know that
Microsoft will continue to build support for the original proprietary
syntax into their products in order to keep them all
backwards-compatible with the early implementations? (something MS
swears by)

Didier say:
You have a point there Lisa. But again, how do we cope with document
composed of multiple transactions? (a jumbo DTD?)
--------------

--------------
Lisa said:
Why doesn't MS use the closest thing it can to the W3C Schema syntax for
now, if it can't wait --rather than an undefined mishmash of two W3C
member submissions and one unfinished white paper from almost year ago?
BizTalk isn't due out till third quarter 99 -- how perfect, neither is
the XML Schema Proposed Recommendation -- how about developing the
BizTalk schemas in conjunction with the Schema Working Group at the W3C
so they are sure to match?! Hey!  THERE's an idea!

Didier reply:
Keeping in synch with W3C is quite hard when the target is moving. They have
shipping constraints so they picked the last proposal until a) this format
becomes a de facto standard or b) the W3C schema takes off. (I am not
defending Microsoft here - just saying that they cannot wait that W3C is
ready). After all, they don't know when the schema spec will be turned into
recommendation.
The problem could be if big companies like SAP, Baans or peoplesoft choose
to include only the old schema reference. This could impose how we send
transaction to big corporations. However, I am sure that for government
transactions, standards will be required (Warning: for government ISO
creates standards, W3C do not necessarily creates standards). However, if we
all agree on e-commerce repositories and the value of these repositories
(like for instance xml.org) then these repositories will call the shot for
normalized document specifications.
---------------

---------------
Lisa said:
That's really what my peeve is with this whole situation.  Microsoft is
in the W3C -- it has people on the schema working group -- why continue
to develop BizTalk behind closed doors?

didier reply:
I guess that to get some equilibrium, repositories like xml.org should
publish document specification rules and how we refer to these document
specifications.
We'll see that quite soon when the military institution will call the shot
how we do e-commerce with them. There is a high probability that the whole
government will follow the same rules. So, Lisa the problem is a bit more
complex than simple technical examination.

a) The US government actually uses EDI standards (either international or
national)
b) Some big corporations also uses EDI standards
c) The government is actually studying to move to XML (SGML) based
transactions. If XML is chosen then they'll give us rules to follow.  The
d) As discussed in the XML-EDI group, a lot of companies want to move toward
XML for B2B transactions.
e) Again, several groups ask for non manufacturer dependent repositories
where transactions document specification will be stored. Documents will
have to follow the repository rules to be valid. The governement will have
its own repository and private business will have probably more than one (I
hope we will all agree on one).
f) A lot of people involved in XML-EDI are facing a dilemma. W3C is not
ready with a schema spec so the void is filled by some manufacturers.
g) most of people involved in XML_EDI think that an independent institution
is needed but should not be W3C but more an international standard
organization like ISO. However the ISO process is slow.

Conclusion:
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
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)
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.
d) And finally interpreters or parsers+interpreters that can validate a
document and interface with back ends ERP. Actually DTD is insufficient to
provide all necessary information, 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.

regards
Didier PH Martin
mailto:martind at netfolder.com
http://www.netfolder.com

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)