[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Fwd:[Fwd: Re[2]: Concern with basic ebXML TRP Syntax/Semanti
I think this discussion is important enough for everyone in ebXML to see and
comment on.
____________________Forward Header_____________________
Subject: [Fwd: Re[2]: Concern with basic ebXML TRP Syntax/Semantics]
Author: Christopher Ferris <chris.ferris@east.sun.com>
Date: 4/7/00 1:30 PM
-------- Original Message --------
Subject: Re[2]: Concern with basic ebXML TRP Syntax/Semantics
Date: Fri, 07 Apr 2000 11:56:39 -0400
From: "Mark CRAWFORD"<mcrawfor@lmi.org>
To: <chris.ferris@East.Sun.COM>
CC: <ebXML-Requirements@lists.oasis-open.org>
Chris,
I think we will have to agree to disagree. My argument all along
has been
that we are about XML, not using the guise of ebXML for individuals to
resurrect
their pet technology standards projects of the last several years. (and
I am not
just talking about TRP, but some of the other efforts within ebXML as
well). If
webMethods can exchange information using XML wrappers, and if BizTalk
can
exchange information using XML wrappers (yes I know they use mime to
encapsulate
binary objects within the XML document instance), then why can't we?
And oh by
the way, if MIME is the answer and simple e-mail attachments are the
best
solution, explain to me how come people still have serious email and
attachment
interoperability problems? Also, if we are going to use MIME as the only
ebXML
solution, which MIME RFC are we going to use?
At a more basic level, there is a philosophy issue that I am afraid
is being
overlooked. In the ISO and IETF world, there is a lot of good standards
work
that goes on by some very smart people, but in many cases that work is
just for
the sake of building standards without regard to who really wants them.
My
clients really could care less about ebXML if it is just rehashing IETF
MIME or
OO technology, or Open EDI, or Business Message Modeling, or X12 SITG
registry
and repository, or any of the other hidden agenda's that I see moving
behind the
scenes of ebXML. I can only sell ebXML as a solution if it provides XML
based
standards for exchange - and more importantly - content. We are not
headed in
that direction, and I am under increasing pressure to just go implement
CommerceOne or webMethods and stop the XML "standards" push. Despite
all the
ebXML stuff about creating an interoperable technical framework, the
real
interest being expressed by my clients is in standardizing the content,
not the
wrapper so they know what data elements they need to support in their
databases
and applications (databases and applications that will not be moving to
an OO
environment for years and years).
If TRP believes that XML technology does not support all of
requirements for
interchange they have addressed, then I believe this is an issue for the
entire
ebXML plenary not just TRP. There are a number of alternatives open -
1) Provide XML solutions for those requirements that can be
addressed
(reduce requirements)
2) Provide dual path XML and MIME solutions
3) Provide a MIME solution and publically state that we are not
developing
XML based solutions, but another MIME standard for exchanging XML
content
because the technology is too immature to support B2B data exchanges.
.
Mark
Mark Crawford
Research Fellow
______
LMI Logistics Management Institute
2000 Corporate Ridge, McLean, VA 22102-7805
(703) 917-7177 Fax (703) 917-7518
mcrawfor@lmi.org
http://www.lmi.org
"Opportunity is what you make of it"
-------------------------------------------------
Chris Ferris Wrote -
Mark,
Not at all! Again, I think that the issue is getting overblown.
The MIME wrapper is merely a means of packaging
XML documents (header information and payload) which
can be:
- parsed separately so that for routing purposes, the
entire message need not be parsed
- separately signed (there might be a different certificate
applied to the header than to the payload)
- include non-XML content such as medical images (JPEG, MPEG)
and more. The MIME use is simply a mechanism which existing
technology can handle, enabling SME's to jump right in without
having to expend significant resources. There does not yet exist
a W3C XML packaging specification to achieve these aims.
Our intent is to submit these requirements to the W3C so that
they are considered in any packaging work and ultimately so that
the ebXML packaging approach can be migrated (in a later
release) to such technology.
Chris
-------------------------------------
Mark CRAWFORD wrote:
> Chris,
>
> Perhaps we should just change our name to ebMime since TRP considers XML
too immature or hard.
>
> Mark
> Mark Crawford
> Research Fellow
---------------------------------------------------------
Chris Ferris Wrote -
Kit,
While I wasn't able to participate the the f2f meeting in
Dallas and can't speak to the finalized packaging minutia
I can address this from the perspective of one of the
members of the packaging sub-team.
We discussed this in depth in the packaging sub-team.
We felt that there was inadequate support in the various
W3C XML recommendations to support our requirements
which follow:
- Able to handle large documents
- Able to envelope any document type
- Minimize intrusion to payload (special encodings or alterations)
- Minimize potential for abnormal termination caused by envelopes
- Facilitate a migration path for existing installed base and
technologies
- Low processing overhead
- Support for recursive documents
- Able to preserve digital signatures
- Able to unambiguously identify signed data
To quote Dick's minutes of our sub-team meeting:
<db>
Both MIME and XML were discussed relative to these requirements. It
was the groups consensus that MIME was better positioned today to
meet the stated requirements. However, it was also believed that XML
would mature as a packaging technology and the ebXML group should
continue to monitor XML's progress for possible inclusion at a later
date.
It was also believed that Microsoft may have addressed some of the
issues affecting XML's packaging ability. Dick Brooks accepted an
action item to contact Microsoft to request information describing
BizTalk's packaging functions to see if this may provide an XML
packaging solution that meets the above requirements.
</db>
Another consideration in our work, and something clearly called out
in the ebXML requirements document are the vision bullets. Specifically:
- is fully compliant with W3C XML technical specifications holding a
recommended status
- maximizes interoperability and efficiency while providing a
transition path from accredited electronic data interchange
(EDI)
and developing XML business standards
The first is key. It refers to W3C technical specifications holding
a *recommended* status. The second is also key. It refers to
a requirement to enable existing solutions such as RosettaNet and
EDI/INT, etc. to interoperate (at least that's how I read it).
This second bullet is called out again in the "General ebXML
Principles" section in the Requirements document. Someone certainly
thinks it s important. I for one concur.
Another consideration which went into our thinking is the availability
of software to handle the package. HTTP and SMTP clients and
servers already support MIME and are both inexpensive and
widely available if not ubiquitous.
In the Requirements document, under the TR&P sub-section, #2
"Leveraging existing technology encompasses both the ability to
interoperate with existing technology as well as the ability to
migrate to the new technology".
In fact, that whole section pretty much sums it up for me.
I believe that there is consensus that ultimately, we will transition
to an XML-based approach to packaging, but at least for the
first go, MIME is the only solution which satisfies all of the
requirements.
To my knowledge, the ebXML Requirements document doesn't
say "use XML to the exclusion of any other technology just because".
MIME seems to meet our requirements and since the content
of the MIME segments is XML (except in cases where an
"attachment" is of some other type such as image, etc.) we're
also meeting the spirit of the ebXML requirements.
If you have knowledge of a purely XML-based packaging
solution which meets all of the stated requirements, and which
the packaging sub team has missed in its considerations, I'm
sure that we'd be glad to reconsider.
Cheers,
Chris
"Kit (Christopher) Lueder" wrote:
> 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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC