RE: EDIINT and the EDI XML movement ...

[carl@xxxxxxxxx]

> Date:          Mon, 7 Dec 1998 15:02:32 -0500 (EST)
> From:          Gunther Schadow <gunther@xxxxxxxxxxxxxxxxxxx>

> Carl,
> 
> 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. :-(

> > XML could represent X12/EDIFACT/HL7 in pretty much exactly the 
> > current form, ....
> 
> Although I agree to you, those are decisions made inside the standards
> 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.

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

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


> > 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'm mostly thinking of many applications like HTTP servers, browsers,
email clients, etc. that configure mappings and only use the single
content-type string.

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

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

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

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

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:carl@xxxxxxxxx> Voice/Fax: 1-408-244-8410      1180 Reed Ave #51
<http://www.chage.com/chage/>                          Sunnyvale, CA 94086