Subject: RE: EDIINT and the EDI XML movement ...

From: "Egerter, Chuck" <[email-masked]>
Date: Sun, 06 Dec 1998 22:06:01 -0500

OBI has not yet released a version of their spec that uses XML.  The team is
just in the beginning phases of discussing how and when to incorporate it.
But... everyone is very optimistic about the benefits that we will gain

Patrick - you may have more to add.

> -----Original Message-----
> From:	[email-masked] [SMTP:[email-masked]]
> Sent:	Wednesday, November 25, 1998 4:04 PM
> To:	[email-masked]; [email-masked];
> [email-masked]
> Subject:	Re: EDIINT and the EDI XML movement ...
> 
> >XML EDI may be relevant in the future. However, currently it seems to
> >be a moving target. As far as I know, neither X12 nor EDIFACT nor HL7
> >have been "converted" significant amounts of their users to XML, ...
> 
> With one big exception: OBI (Open buying on the internet) use of XML for
> X12 850 purchase order.
> 
>     _/    _/             Kit C. J. Lueder       
>    _/   _/         _/   The MITRE Corp.         Tel:  703-883-5205
>   _/_/_/    _/  _/_/_/ 1820 Dolley Madison Bl  Page: 703-331-7656
>  _/   _/   _/    _/   Mailstop W658           FAX:  703-883-3383
> _/    _/  _/    _/   McLean, VA 22102        Mail: [email-masked]
> God offers to every mind its choice between truth and repose
> - -Emerson, Essays: Intellect

---

From: Gunther Schadow <[email-masked]>
Date: Tue, 8 Dec 1998 11:40:43 -0500 (EST)

Carl,

> > > I think it would be MUCH better to use: Content-type:
> > > application/edi-xml-hl7,
> > 
> > It may be a matter of taste, don't you think so? Let's for one more
> > time pick out the old ISO/OSI protocol layer model.
> ...
> > I think it is worthwhile to distinguish
> > application/edi-hl7 as the application layer protocol and then make
> > the minor distinctions between presentation syntax in the "syntax"
> > parameter.
>
> Sure I agree that from a layering point of view this makes most 
> sense. But if you look at how Content-type is used, most tools that
> deal with MIME simply take this value, e.g. "application/edi-hl7"
> and map it to some processing application, e.g. "HL7View.EXE". Most
> likely, a different tool would be needed to process XML syntax for
> a message.
[...]
> I'm mostly thinking of many applications like HTTP servers, browsers,
> email clients, etc. that configure mappings and only use the single
> content-type string.

when I experimented with metamail, it gave me access to the parameter
list, and I always had the feeling that the Netscape way of doing
things is heavily based on metamail. But I didn't reconfirm my feeling
with facts. While I see your point here, this argument might not be
very persuasive because EDI messages are not primarily meant to be 
viewed in a browser anyway. The reason why I still prefer the SYNTAX
parameter (and the other parameters defined in the EDIINT-HL7 draft) is
that I would like to keep the management of those parameter values
in the realm of HL7 rather than to bother IETF with those.

> > >...Maybe what you want is, "Content-Type: xml/edi-hl7".
> > 
> > This would suggest adding XML as a new major MIME type besides text,
> > image, audio, application, message, and model. And I don't think that
> > XML is ever so outstanding to be a candidate for a major MIME type.
>
> Yes, it would mean a major type-- I don't know either if this would
> ever be so outstanding. The idea being the major type "text" is 
> viewable with a text editor, no matter the subtype. Likewise, XML
> might be "viewed" or processed with a general purpose XML processor.
> Of course, maybe it's "text/xml" in general form?

it could be text/xml if the primary disposition is to view the EDI
message rather than to chew it into the EDI digestion tract. For
chewable messages I would still prefer application/edi-*.

> > XML doesn't have to use DTDs. In fact, in HL7 we have decided not to
> > require the use of DTDs. Our messages are basically fine with the
> > well-formed requirement of the XML standard and we wanted to have more
> > flexibility than DTDs can give us. Again, this is a question outside
> > the scope of EDIINT.
>
> (Yes, this is more of an XML-EDI issue.) Presumably you've defined 
> some mapping between the HL7 standard and XML element and attribute
> names. (Do you have a URL for how HL7 intends on doing this?) Even
> if you never create a DTD, there is an implicit DTD. If available,
> then some non-HL7 applications would be able to process HL7-XML.

HL7 generates all its messages in a semi-automatic process from its
major reference information model (RIM) that is usually presented in
UML (Rose). This process has multiple steps, that we are currently
still experimenting with. At the end, we have a truely abstract syntax
definition for the messages. This definition may then be mapped fully
automatically to an implementation technology according to an
Implementation Technology Specification (ITS). The main ITSs we have
in mind are: XML syntax for messages, distributed objects (CORBA,
DCOM) and traditional EDI style (segments etc.).

Now on the XML side we do not necessarily have a DTD but we probably
do not prevent an "implicit DTD". However, there is not necessarily
a sensible implicit DTD. There are some major problem with DTDs:

1. although the XML tags would in principle not require adherence to a
   particular sequence, XML DTD's require you to stick to the one
   sequence required by the content model.

2. there is no name scoping with DTDs, i.e. suppose you have two
   classes "RemoteHost" and "Person" both of which have an attribute
   named "address" but of different type (IP-address vs. residential
   address). A name conflict occurs. To prevent that, you must
   enforce unique names at all levels of nesting and in your
   information model, which is not quite what modern software 
   engineering has tought us to do :-)

3. you have to engage in the battle: is it an element or an attribute?
   This battle is so time consuming and at the same time meaningless,
   that I decided to use XML only through an interface that maps all
   attributes to elements so that I have uniform parse tree nodes.

Of course there are work arounds for all of those problems, some are
ridiculous (i.e., specify you content model as the union of all
possible permutation of a sequence), some are more straight forward
(i.e. prefix the name of attributes with the name of the class). But
after all those lengthy battles, I haven't seen any compelling
argument for the use of DTDs.

> > XML is just another presentation syntax. I am opposed to create an
> > equivalence class of disparate application protocols only on the
> > criterion that they use the same presentation rules.
>
> But according to all the marketing people, XML is the solution to all 
> the worlds problems! From what I read, as long as companies encode 
> thier data with XML, all applications can autmocatically talk with 
> each other ;-) 

Oh, come on. Please keep at least the IETF world free of that
hype. People are so crazy about XML nowadays. I almost feel like an
old man. Recently I heard Tim Berners-Lee in a talk on the future of
the Web and he went way off ground with all that Metadata idea. I'd be
happy if we could do information modeling in peace, and I would be
most happy if there would not be any more new initiative on EDI and
XML. It's already too much. The problem is we want to harmonize EDI
efforts. The more groups are created, the more difficult will be the
job.

Before XML, we finally came to an agreement that it doesn't matter
whether we use plus signs (EDIFACT), asterisks (X12) or verticle bars
(HL7) as our data field separators. We finally came to acknowledge
that harmonization means primarily to harmonize information models and
process structures. Now XML came in and touted that a new syntax would
fix all our problems! I could almost laugh and cry at the same time!

Let us be one sane group of people in an unsane world. A group of
people who (hopefully) learned in school what a module is, what
encapsulation and interfacing is, and why those things are good for
you.

regards
-Gunther

Gunther Schadow ----------------------------------- http://aurora.rg.iupui.edu
Regenstrief Institute for Health Care
1001 W 10th Street RG5, Indianapolis IN 46202, Phone: (317) 630 7960
[email-masked] ---------------------- #include <usual/disclaimer>

---

From: Brain <[email-masked]>
Date: Wed, 9 Dec 1998 15:49:26 -0600

It certainly makes sense to me to support XML.

-----Original Message-----
From:	RIK drummond [SMTP:[email-masked]]
Sent:	Wednesday, December 09, 1998 2:13 PM
To:	Gunther Schadow; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc:	[email-masked]
Subject:	RE: EDIINT and the EDI XML movement ...

So are you'all feeling that we should support xml as part of the ediint
standards?

regards, rik

> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Gunther Schadow
> Sent: Monday, December 07, 1998 9:55 AM
> To: [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: EDIINT and the EDI XML movement ...
>
>
> That's exactly what I meant: everyone is looking at XML and is planning
> to use it. So is HL7, so is X12, so is EDIFACT (?), everyone may be
> at a slightly different stage in the process (e.g. HL7 is almost
> committed to using XML for its version 3 and is planning on a demo
> for Spring 1999. But the bottomline for now is: noone is really done,
> and if someone where done with the specs, the broad user base is still
> not there. Give it some more time.
>
> But anyway, the part that was removed from my original message was that
> I don't believe XML presentation syntax puts a lot of new requirements
> to EDIINT protocols. The only thing that I conceive necessary is to
> introduce a parameter "syntax" for the MIME-EDI container so that the
> message processor can select the appropriate parser:
>
> Content-type: application/edi-hl7; syntax="xml"
>
> <HL7MSG ...>
> ...
> </HL7MSG>
>
>
>
> or
>
> Content-type: application/edi-hl7; syntax="traditional"
>
> MSH|...|||||
> BLA|||||
> BLA|||||
>
>
> This parameter "syntax" is already part of the current HL7 EDIINT
> draft. At last, we might want to think about revising RFC 1767
> (MIME-EDI).
>
> regards
> -Gunther
>
> From: "Egerter, Chuck" <[email-masked]>
> Date: Sun, 06 Dec 1998 22:06:01 -0500

---

From: Gunther Schadow <[email-masked]>
Date: Wed, 9 Dec 1998 16:43:10 -0500 (EST)

Rik,

> So are you'all feeling that we should support xml as part of the ediint

ANSWER: Yes, we should support XML no worse than we support any other
presentation layer protocol for EDI.

ACTION ITEMS: none specific to XML.

BUT WHAT?: The only thing we may want to do is to get a common sense
on how we deal with different presentation layer protocols for the
same EDI standard.

The thread between Carl Hague and me lays out the issues.

The HL7 draft has taken one position. If there is major opposition to
the SYNTAX parameter, please raise your hands ASAP, since I heard Rik
issuing "last call" lately.

If there is no significant opposition, my question to you all is: do
you want to generalize this parameter for use with the other EDI
MIME types (edi-x12, edifact) too?

Rik: you issued the last call for all of the IETF documents at once. I
am pleased to see things being flushed now. My procedural question is:
how do we prepare the text for RFC issues? At least we have to resolve
all the mutual cross references to Internet drafts. And we may want to
revise/update some of the other references too (e.g. recent open-PGP
and SMIME v3 stuff). Also, as I am preparing the HL7 document for vote
within HL7, I came/will come accross some minor typos. What is the
exact schedule now with regards to your "last call"?

regards
-Gunther