VS: Concern with basic ebXML TRP Syntax/Semantics

[Matti.Vasara@fingrid.fi]

I have the same concerns, a way with VPN for authentication, XML envelope
for transport on https and routeing (possible packaking, encryption) and xml
payload for application could be much simpler.
Matti Vasara

> -----Alkuperäinen viesti-----
> Lähettäjä:	Kit (Christopher) Lueder [SMTP:kit@mitre.org]
> Lähetetty:	6. huhtikuuta 2000 22:00
> Vastaanottaja:	ebXML-Transport@lists.oasis-open.org
> Aihe:	Concern with basic ebXML TRP Syntax/Semantics
> 
> I have a concern with the basic ebXML TRP approach. As I indicated last
> month, as far as I know, the TRP approach is in conflict with the ebXML
> Requirements specification. If I understand right, the ebXML TRP
> solution is MIME based only, which is not an XML solution.
> 
> I quote the last paragraph from Section 1 Introduction of the ebXML
> Requirements:
> "A key aspect for the success of the ebXML initiative is adherence to
> the use of the W3C suite of XML and related Web technical
> specifications.  Although these specifications may not provide the
> optimal technical solution, acceptance of ebXML by the business
> community and technical community is tied to XML.  Alternative
> technologies and technical specifications may be incorporated as part of
> the ebXML solution.  However these alternative technologies and
> specifications will only be provided as an alternative to the provided
> XML solution unless the W3C XML and related Web technical specifications
> can not accomplish the same business functionality."
> 
> Kit.
> 
> 
> Todd Boyle wrote:
> > 
> > I would appreciate any information or links regarding the duplicated
> > or overlapping information in multiple layers of headers and wrappers.
> > My understanding is that a typical ebXML message might contain
> > 
> >   HTTP/MIME multipart/related header
> >     ebXML header
> >     payload1
> >       Biztalk, or MSMQ/MQseries etc. header
> >       Biztalk, or MSMQ/MQseries etc. header
> >          Rosetta, OAG, CBL2, etc. document
> >              Rosetta, OAG, CBL2, etc. required document header
> >                  The XML message content which would usu. include
> >                  all the parties' identities and reference codes
> >     payload2
> >     payload3   etc.
> > 
> > No doubt I've got this screwed up someplace.  I imagine for the coming
> > 12-24 months MOM or MQ servers will be required no matter what ebXML
> > comes up with, and accordingly ebXML header and MOM headers will both
> > be transported?
> > 
> > My real question is, how to eliminate all duplication and if that is
> > impossible, will there be a need for applications which navigate
> > up and down the layers of headers to ensure they are consistent?
> > 
> > Todd Boyle
> > 
> > Christopher Ferris said 4/3
> > > IMHO, our role should be to provide the content for the semantic
> > > meaning of the elements we include in the header, etc. as well as
> > > any information related to semantic equivalence with other existing
> > > standards such as RosettaNet, EDI/INT, etc.
> > 
> > [...]
> > > > 2. namespaces
> > > >
> > > > MILR: Namespace can help avoid element name clashes, but IMO it
> doesn't
> > > > addresss the equivalence of semantic entities across namespaces.
> > > > Each option should be explored for possible appication within the
> ebXML
> > > > header specification.
> > > > I firmly believe the issues you raise, relative to the actual
> business
> > > > transactions, needs to be addressed by the parties responsible for
> > > > specifying these standards (e.g. OTA, et al).
> > > >
> > > > MILR:  I believe ebXML must adopt some XML syntax rules that
> adequately
> > > > address the issue of semantics...
> 
> -- 
>     _/    _/             Kit C. J. Lueder       
>    _/   _/         _/   The MITRE Corp.         Tel:  703-883-5205
>   _/_/_/    _/  _/_/_/ 1820 Dolley Madison Bl  Cell: 703-577-2463
>  _/   _/   _/    _/   Mailstop W722           FAX:  703-883-7996
> _/    _/  _/    _/   McLean, VA 22102        Mail: kit@mitre.org
> Worse than an unanswered question is an unquestioned answer.