RE: EDIINT and the EDI XML movement ...

[Gunther Schadow <gunther@xxxxxxxxxxxxxxxxxxx>]

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
schadow@xxxxxxxxxxxxxxxxxxx ---------------------- #include <usual/disclaimer>