RE: EDIINT and the EDI XML movement ...

[carl@xxxxxxxxx]

> Date:          Mon, 7 Dec 1998 10:54:51 -0500 (EST)
> From:          Gunther Schadow <gunther@xxxxxxxxxxxxxxxxxxx>
> To:            chuck.egerter@xxxxxxxx, clueder@xxxxxxxxxxxxxxxx,
>                gunther@xxxxxxxxxxxxxxxxxxx, ietf-ediint@xxxxxxx,
>                John.Mani@xxxxxxxxxxx

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

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.

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

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

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.

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.

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

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.

The edi-xml standard might also require that the schema-definition be 
available at a URL, encoded in XML. Rather than reference just an 
SGML DTD (syntax-only), an XML declaration of the syntax, semanticsm, 
and documentation must be available for reference. Paper-only 
standards could not be edi-xml compliant-- a net-accessable 
definition of the semantics should be mandatory. This XML schema 
definition would be used by tools that manipulate the data, and might 
be referenced in a separate data-mapping schema/table. An edi-xml RFC 
would not need to specify a specific schema-definition schema, but 
could allow arbitrary (extensible) schema definitions, e.g. 
XML-Schema, XML-Data, etc. The schema-definition schema should 
identify itself with a URI to a DTD, however.

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:

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.

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.

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.

4. To provide an infrastructure to represent schema definitions
as online referencable documents:

a) to allow data mapping utilities (e.g. translator between 
protocols) to cross-reference data-element/schema definitions,
e.g. with an XML Pointer/Link

b) to allow XML-based implementation convention and/or extension 
definitions to be layered on top of other online XML-based standard 
schema definitions.
--------------------------------------------------------------------------
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