RE: Lotsa laughs
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@n... http://www.netfolder.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i... 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@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format