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

From: Gunther Schadow <[email-masked]>
Date: Mon, 7 Dec 1998 15:02:32 -0500 (EST)

Carl,

nice to hear back from you. Heaven't read your voice for quite a while
:-).

> XML could represent X12/EDIFACT/HL7 in pretty much exactly the 
> current form, and a simple mapping of names and/or tag definitions
> would suffice. However, it would be much better to reorganize the 
> structure to something more logical (simple object oriented) than the 
> rather limiting X12 style segments. HL7 seems much better in this 
> respect as it seems more logical to me.

Although I agree to you, those are decisions made inside the standards
body (i.e. X12, HL7, EDIFACT) rather than on the level of EDIINT. So
we don't have to (and should not) be concerned with how that XML stuff
look like. 

> > 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"
>
> 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. There we have
application layer (7) protocols, which for instance are HL7 or
X12. Then there is one or more presentation layer (6) protocol
possible for the same application layer protocol. I.e. for HL7 version
2.3 there might be two presenation layer instances: (a) traditional
encoding rules and (b) XML. 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. This is what the current HL7 Internet draft suggests (and
which will go into the RFC submission if not defeated by anyone).

> or even "Content-type: application/edi-xml", then use a URI to a DTD
> to indicate HL7 or whatever. The content (sub)type should indicate 
> the syntax. 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.

> A new parameter will cause existing MIME processors to fail, wheras
> creating new types (e.g. with a prefix/suffix on the MIME content 
> type name), would allow applications to be configured to pass data to 
> a XML processor, pass data to a traditional processor, or detect that 
> no support is available for XML.

That's right. Although you could also say that (1) currently there is
no choice of syntaxes anyway. (2) If we want that choice to be made,
we have to add either a new MIME minor type or extend the spec of
MIME-EDI. No matter what you do, the old software would not be able to
use it. (3) If we would use the SYNTAX parameter, than we can specify
a default rule to the old syntax, and thus have backwards
compatibility.

> I can't think of a reason (other than reduce the number of edi-xx 
> names) why using separate content-type names wouldn't be best. An 
> older program requires separate names, whereas a new one doesn't 
> require a common name.

What are the reasons for parameters then? May be you're right, may be
you're wrong, may be it is just a matter of style.

> > 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).
>
> I would oppose adding a new parameter to the Content-Type, but 
> support adding new edi-xx types to support XML-based protocols. I 
> think it would be useful to define "application/edi-xml", with
> some requirements on XML usage, e.g. there is an external DTD 
> reference with a URI that uniquely identifies the base standard 
> and/or message type. That way a general purpose XML processor could 
> be created, which could handle several standards and could be easily 
> extensible.

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.

> An edi-xml RFC might specify guidelines for the DTD URI, e.g. that it 
> be a net-accessable document, indentifying the standard and a source
> of info on the standard, e.g. a http: URL to an HTML file, with META 
> links to the DTD, etc. Also, there could be guidelines for a URI to 
> implementation conventions or extensions layered on top of the 
> base-standard. This RFC might require standards setting organizations 
> to declare a URI prefix for all DTDs for standards sanctioned by that 
> organization.

I don't see IETF EDIINT to have any business with such a specification
and I don't think it would add any more value on the many EDI/XML
movements that are currently out there. Let the EDI standards orgs get
clear about their use of XML first and then we'll see how much of that
stuff needs to be reflected by IETF EDIINT or any other IETF working
group.

> There could also be a set of protocol/standard specific suffixes,
> e.g. application/edi-xml-hl7, application/edi-xml-obi, etc.
>
> The purpose of an "application/edi-xml" content-type would be:

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. You would not
define

application/edi-ber
application/edi-cer
application/edi-der
application/edi-xdr
application/edi-java-object-serialization

only because those respective presentation syntax rules are used. The
higher order category is whether you have an

edi-hl7
edi-x12
edifact
...

message. Everything else is subordinate.

> 1. To define a top-level EDI protocol which could represent many EDI 
> standards, using XML syntax as a data exchange format, representing 
> standard-specific protocols with a 1:1 mapping.

There is no such a thing as a 1:1 mapping between languages and
application protocols. Many things are alike, but the devil is found
in the detail. And here you find fine nuances of meaning and radically
different views of the world, both of which can not be mapped 1:1.

> 2. To permit general purpose applications to manipulate EDI data 
> independent of the base standard and with the ability to easily 
> process new standards that might be developed in the future.

That's not the way it works, and, again it is out of EDIINT's scope.

> 3. To create a means where general purpose XML-EDI processing 
> software can access a DTD, semantics, and documentation via online 
> URL, in order to load data validation information, help info, print
> formatting, etc.

Oh, this would be nice, but (aside from repeating myself about scope)
the problem is that standards organizations consider their specs a
source of revenue and are *very* reluctant to put it out into public
online access. Not everyone is as public as IETF.

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: [email-masked]
Date: Mon, 7 Dec 1998 17:45:29 -0800

> Date:          Mon, 7 Dec 1998 15:02:32 -0500 (EST)
> From:          Gunther Schadow <[email-masked]>

> nice to hear back from you. Heaven't read your voice for quite a while

I've been to busy to have fun meddling in email discussions. :-(

> > current form, ....
> body.

Agreed. It would be nice, however, if each of these standards bodies
created an XML schema definition as net-referencable XML, which 
would be something that crosses standards bodies, i.e. is something
within the realm of XML standards developers.

> time pick out the old ISO/OSI protocol layer model.
...
> I think it is worthwhile to distinguish
> 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.

> >...Maybe what you want is, "Content-Type: xml/edi-hl7".
> 

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?

> a default rule to the old syntax, and thus have backwards

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.

> flexibility than DTDs can give us. Again, this is a question outside

(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.

> 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 ;-) 

Sure, XML as just a presentation syntax doesn't do much except make 
parsing data easier or harder, depending on your point of view. What 
could make a difference, in my opinion, is to standardize (in a more 
generalized way) ways to define semantics of XML content. (Beyond the 
scope of the current IETF-EDI RFC, but perhaps would be of interest 
to the IETF-EDI WG as a separate effort.)

...
> application protocols.

All I meant was 1:1 mapping between a particular standard (e.g. HL7) 
and the XML encoding of data in that standard, e.g. the mapping 
defined by HL7 to define the syntax (element names) for XML HL7.
--------------------------------------------------------------------------
Carl Hage                                              C. Hage Associates
<mailto:[email-masked]> Voice/Fax: 1-408-244-8410      1180 Reed Ave #51
<http://www.chage.com/chage/>                          Sunnyvale, CA 94086