RE: EDIINT and the EDI XML movement ...

[Gunther Schadow <gunther@xxxxxxxxxxxxxxxxxxx>]

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