Re: AS2 XML requirements

Sorry, I guess I read that as the opposite of the authors' intention.
Yes, I advocate expanding the types. I think something like an
"XML-consent" MIME type (or "edi-XMLconsent" if you prefer) would
provide a general mechanism of carrying XML content that the recipient
knows needs to be handed to the XML parser. I consider XML to be a type
of EDI in the general sense (not the X12/Edifact sense), since it is
structured data, computer processable. 

Yes, I know that HL7 can be encoded in XML, but if you are happy using
the edi-hl7 tag for HL7 XML, that is fine too. It seems like a burden on
you to figure out which encoding you are using for HL7, but if you
aren't worried about it, I'm not either. Personally, I would have a tag
of "edi-hl7XML"...
Kit.

Dick Brooks wrote:
> 
> Kit,
> 
> Nobody is suggesting that AS1 be changed to say that all examples be based
> on RFC1767. The problem is that all AS1 examples ARE based on RFC 1767. I,
> and others (yourself included, I presume), are advocating the expansion of
> AS1 to explicitly include support for other MIME types.
> 
> Dick Brooks
> Group 8760
> 110 12th Street North
> Birmingham, AL 35203
> [email protected]
> 205-250-8053
> Fax: 205-250-8057
> http://www.8760.com/
> 
> InsideAgent - Empowering e-commerce solutions
> 
> > -----Original Message-----
> > I don't get it. Why should we change AS1 by saying that "all examples
> > are based on RFC 1767 payloads"? Are we trying to squash extensibility?
> > Kit.
> >
> > Dick Brooks wrote:
> > >
> > > > > supported in AS1. The AS1 specification is tightly intertwined with
> > > > > references to RFC 1767 and all examples are based on RFC
> > 1767 payloads.
> > > > Now is the time to add this definitive text to AS1.
> > >
> > > I totally agree. For consistency I suggest using similar text as what
> > > appears in section 2 on page 6 of AS2.
> >
> >
> > Chris Davenport wrote:
> > > I'm quite happy to see the EDI-consent sub-type disappear.  As Gunther
> > > was at pains to point out a couple of years ago, it raises important
> > > interoperability issues.
> >
> > Ouch. That would make edi-int gradually become useless and irrelevant, I
> > think, as XML and other internet technologies evolve. The problem that
> > needs to be solved is that there is no good extensibility mechanism in
> > edi-int.
> > Kit.
> >
> > --
> >     _/    _/             Kit C. J. Lueder
> >    _/   _/         _/   The MITRE Corp.         Tel:  703-883-5205
> >   _/_/_/    _/  _/_/_/ 1820 Dolley Madison Bl  Cell: 703-577-2463
> >  _/   _/   _/    _/   Mailstop W658           FAX:  703-883-3383
> > _/    _/  _/    _/   McLean, VA 22102        Mail: [email protected]
> > Worse than an unanswered question is an unquestioned answer.
> >

-- 
    _/    _/             Kit C. J. Lueder       
   _/   _/         _/   The MITRE Corp.         Tel:  703-883-5205
  _/_/_/    _/  _/_/_/ 1820 Dolley Madison Bl  Cell: 703-577-2463
 _/   _/   _/    _/   Mailstop W658           FAX:  703-883-3383
_/    _/  _/    _/   McLean, VA 22102        Mail: [email protected]
Worse than an unanswered question is an unquestioned answer.