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

From: Gunther Schadow <[email-masked]>
Date: Mon, 7 Dec 1998 10:54:51 -0500 (EST)

That's exactly what I meant: everyone is looking at XML and is planning
to use it. So is HL7, so is X12, so is EDIFACT (?), everyone may be
at a slightly different stage in the process (e.g. HL7 is almost
committed to using XML for its version 3 and is planning on a demo
for Spring 1999. But the bottomline for now is: noone is really done,
and if someone where done with the specs, the broad user base is still
not there. Give it some more time.

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

<HL7MSG ...>
...
</HL7MSG>

or

Content-type: application/edi-hl7; syntax="traditional"

MSH|...|||||
BLA|||||
BLA|||||

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

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: "Egerter, Chuck" <[email-masked]>
Date: Sun, 06 Dec 1998 22:06:01 -0500
> OBI has not yet released a version of their spec that uses XML.  The team is
> just in the beginning phases of discussing how and when to incorporate it.
> But... everyone is very optimistic about the benefits that we will gain
>
> Patrick - you may have more to add.
>
> > From:	[email-masked] [SMTP:[email-masked]]
> > Sent:	Wednesday, November 25, 1998 4:04 PM
> > To:	[email-masked]; [email-masked];
> > [email-masked]
> > Subject:	Re: EDIINT and the EDI XML movement ...
> > 
> > >XML EDI may be relevant in the future. However, currently it seems to
> > >be a moving target. As far as I know, neither X12 nor EDIFACT nor HL7
> > >have been "converted" significant amounts of their users to XML, ...
> > 
> > With one big exception: OBI (Open buying on the internet) use of XML for
> > X12 850 purchase order.
> >

---

From: [email-masked]
Date: Mon, 7 Dec 1998 11:16:49 -0800

> Date:          Mon, 7 Dec 1998 10:54:51 -0500 (EST)
> From:          Gunther Schadow <[email-masked]>
> To:            [email-masked], [email-masked],
>                [email-masked], [email-masked],
>                [email-masked]

> 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

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.

> draft. At last, we might want to think about revising RFC 1767

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

---

From: "RIK drummond" <[email-masked]>
Date: Wed, 9 Dec 1998 14:12:49 -0600

So are you'all feeling that we should support xml as part of the ediint
standards?

regards, rik

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Gunther Schadow
> Sent: Monday, December 07, 1998 9:55 AM
> To: [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: EDIINT and the EDI XML movement ...
>
>