[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Fwd:RE: [Fwd: Re[2]: Concern with basic ebXML TRP Syntax/Sem
I completly agree with James McCarthy in that taking the approach that we
(Microsoft took) i.e
If a message has only XML types then packaging multiple XML document
instances as a
single XML Document separated by name spaces and using a SAX compliant
parser to
process it is very efficient and possible
If a message contains mixed types then packaging all the XML document
instances in a
single MIME part and each of the other parts as other MIME parts is a
reasonable
approach that also works.
Taking this approach has been found to work and does not seem to burden the
processing of most XML based business messages which today are not of mixed
types, yet allowing the border cases where there are some messages that
could be of mixed type.
NOTE: The reason I think folks like RosettaNet took and anybody else who has
based there packaging structure assuming DTD's as three or more separate XML
documents each packaged as individual MIME parts is that with DTD's you did
not have the luxury of using "Name Spaces" as you can more easily with
XML/XDR as well as XML/XSD combinations.
-----Original Message-----
From: Prasad Yendluri [mailto:pyendluri@vitria.com]
Sent: Monday, April 10, 2000 6:44 PM
To: James McCarthy
Cc: ebXML Transport (E-mail)
Subject: Re: [Fwd: Re[2]: Concern with basic ebXML TRP Syntax/Semantics]
Hi,
Other frameworks like RosettaNet have discovered that it is desirable to
keep
the envelope and content disjoint (i.e. two different XML documents packed
together (with MIME) instead one XML document).
Some of the advantages are:
1. Having fixed header DTD / Schema makes it easier / efficient to route the
message without having to look into the business content.
2. Clear separation between different business (payload) documents and
headers
so that headers can be changed without impacting all business documents.
3. Error can be reported back even if the business content can not be
parsed.
Prasad
James McCarthy wrote:
> > -----Original Message-----
> > From: owner-ebxml-transport@lists.oasis-open.org
> > [mailto:owner-ebxml-transport@lists.oasis-open.org]On Behalf Of Dick
> > Brooks
> > Sent: Monday, April 10, 2000 5:41 PM
> > To: srh@us.ibm.com; David Burdett
> > Cc: Jon Bosak; ebXML-Transport@lists.oasis-open.org; Nicholas Kassem
> > Subject: RE: [Fwd: Re[2]: Concern with basic ebXML TRP Syntax/Semantics]
> >
> >
> > The packaging sub-group has spent several weeks coming up with this
design
> > and now it seems some people want to "unravel" it and start all
> > over again.
> > If we keep revisiting and rehashing decisions we will not meet our
> > deadlines.
> >
>
> No one is trying to "unravel" anything. The only real change that was
> suggested was that all pure XML content is packaged in a single MIME part
> using namespaces. This is currently being done by the Biztalk
specification
> and I have written SAX handlers to parse these messages. All non-XML will
> NOT be in the XML envelope but in separate MIME parts following the XML
> portion of the message.
>
> I think this is a very reasonable approach which is a great compromise
> between pure XML and MIME and takes full advantage of both specifications.
> MIME to separate mixed message types and namespaces to separate multiple
XML
> body parts all represented by a single ebXML header.
>
> > The packaging sub-group discussed one container versus two and the
reasons
> > we decided on two containers follow:
> >
> > - One XML container means that the entire document (which could
> > be GIGABYTES
> > of data) would have to be processed/parsed as a single XML document.
This
> > would make processing time slow and could seriously impact response
time.
> >
>
> If the GIGABYTES of data is pure XML, IMHO, it is easier to process this
as
> an input stream using a SAX handler than it is to have to first separate
the
> message from its outer wrapper, MIME, and then parsing it using an XML
> parser.
>
> > - There is no XML based standard for packaging mixed payloads. The ebXML
> > group would have to create a XML based packaging standard and this
didn't
> > seem practical when we could very easily apply MIME to a task it was
well
> > designed to handle. this also met the group requirement to use existing
> > solutions whenever possible (don't re-invent the wheel).
> >
>
> MIME will still be used for this no one is suggesting a change here.
>
> > - There is a large installed base of products that support MIME and
> > developers who are familiar with MIME. Scott, MIME is not that
"difficult"
> > to process - I'll bet I could teach you how to process the ebXML MIME
> > envelope in less than two hours using MIME++, assuming you're
> > familiar with
> > C++ ;^).
> >
> > I assert that a MIME solution using two "containers", is superior to a
> > single XML container for for the following reasons:
> > - there are no illeagal characters to deal with in MIME as
> > there are in XML
> > (& < all have to be transformed)
> > - there are mature, proven packages available to parse MIME, an
XML
> > solution would have to be developed
> > - binary objects are transportable without any conversion
> > with MIME (no
> > base64 needed when using HTTP transport);
> > with XML binary objects must be base64 encoded
> > - applying base64 to a payload adds appx 40% to its size
> > and this adds time
> > to transmit and process.
> > - There are already MIME based STANDARDS for packaging a
> > significant body
> > of objects (jpeg, EDI, XML, html, et al), these would all have to
> > be created
> > for an XML based packaging solution.
> >
>
> David's original post on this thread did not suggest a single package for
> everything. MIME would still be used and would be required for mixed
> payloads.
>
> > Some people have suggested using the existing MIME headers and media
types
> > to create an XML packaging specifcation, then we could have MIME in XML.
> > Why - what is the benefit of this - the ability to say we have a pure
XML
> > packaging solution?
> >
> > The packaging sub-group is certainly open to a better solution - if one
> > exists. Please announce to the list any STANDARD based XML packaging
> > solutions that we should consider, please be sure to include how
> > the issues
> > above are addressed.
> >
> > Thank you,
> >
> > Dick Brooks
> > http://www.8760.com/
> >
> >
> >
> > -----Original Message-----
> > From: srh@us.ibm.com [mailto:srh@us.ibm.com]
> > Sent: Monday, April 10, 2000 3:34 PM
> > To: David Burdett
> > Cc: 'dick@8760.com'; Jon Bosak; ebXML-Transport@lists.oasis-open.org;
> > Nicholas Kassem
> > Subject: RE: [Fwd: Re[2]: Concern with basic ebXML TRP Syntax/Semantics]
> >
> >
> >
> >
> > David,
> > This was going to be my next question coming out of the Dallas meeting.
> > ---- why do we *need* the header envelope to be a seperate mime part
from
> > the payload envelope? ----
> >
> > Without it, as you describe, essentially decouples the core ebXML
> > spec from
> > the lower level transport,
> > and essentially only demands that an application use a mime-based lower
> > transport only if binary
> > passed-by-value is required with high performance. As before, nothing
> > precludes an application
> > from base64ing a binary pass-by-value payload, and still leverage the
core
> > ebXML TRP specs
> > consistently over a transport that has nothing to do with mime.
> >
> > Somebody shoot this down. I think its difficult.
> >
> > Scott R. Hinkelman
> > IBM Austin
> > SWG Java Solutions
> > XML/Java Standards Architecture
> > Office: 512-823-8097 TL793-8097
> > Home: 512-930-5675
> > Cell: 512-940-0519
> > srh@us.ibm.com
> > Fax: 512-838-1074
> >
> >
> >
> > David Burdett <david.burdett@commerceone.com> on 04/10/2000 01:37:33 PM
> >
> > To: "'dick@8760.com'" <dick@8760.com>, Jon Bosak
> > <Jon.Bosak@eng.sun.com>,
> > ebXML-Transport@lists.oasis-open.org, Nicholas Kassem
> > <Nick.Kassem@eng.sun.com>
> > cc:
> > Subject: RE: [Fwd: Re[2]: Concern with basic ebXML TRP
Syntax/Semantics]
> >
> >
> >
> >
> > Now this may be off the wall somewhat, but there might be a way
> > that we can
> > provide support for BOTH XML and MIME. The basic idea is described in
the
> > following structure that just *might* work. What you would have is:
> >
> > 1. A MIME outer wrapper that contains:
> > a) an initial MIME part that contains:
> > i) a single XML document that contains:
> > * a mandatory Message Header element that contains
> > several header parts as are being developed/
> > discused on this list
> > * zero or more body parts that each consist of XML payloads,
> > where each payload has a single XML element that has a
> > separate XML namespace
> > b) zero or more additional MIME parts that can contain
> > anything that is *not* XML
> >
> > This way, if you only needed XML, then you would have no additional MIME
> > parts. On the other hand if you did need non-XML documents then you
could
> > use separate MIME parts to hold it.
> >
> > This also resolves the real problem with XML in that you can't put XML
> > inside XML without, either base64 encoding it (CDATA doesn't work
> > since you
> > can't put CDATA inside CDATA).
> >
> > Thoughts?
> >
> > David
> >
> >
> >
> > -----Original Message-----
> > From: dick@8760.com [mailto:dick@8760.com]
> > Sent: Saturday, April 08, 2000 8:53 AM
> > To: Jon Bosak; ebXML-Transport@lists.oasis-open.org; Nicholas Kassem
> > Cc: dick@8760.com
> > Subject: Re: [Fwd: Re[2]: Concern with basic ebXML TRP Syntax/Semantics]
> >
> >
> > The packaging group investigated every "lead" in the search for a pure
XML
> > packaging solution. I asked David Turner from Microsoft if they had a
pure
> > XML
> > packaging solution, he never responded. Some other proposals looked
> > promising
> > (XMTP, for example), but none were on a standards track with any
standards
> > making body.
> >
> > Nick is 100% on the mark. The ebXML packaging specification DOES support
> > pure
> > XML payloads, as well as other non-XML payloads. The reason we chose
MIME
> > to
> > encapsulate the ebXML header (which is pure XML) and Payload (be it XML,
> > EDI,
> > JPEG, text, et al) is because we could not find a STANDARDS TRACK
"pure
> > XML"
> > packaging solution that provided the capabilities of MIME.
> >
> > The bottom line is, MIME is the ONLY standard packaging technology
> > available
> > that meets the ebXML requirements for Transport, Routing and Packaging.
> > However,
> > the packaging group does recognize that a XML based packaging standard
> > could
> > emerge and for this reason the specification will "leave open" the
> > possibilities
> > of a pure XML packaging solution becoming part of the specification in
the
> > future.
> >
> > Dick Brooks
> > http://www.8760.com/
> >
> >
> >
> > ----- Original Message -----
> > From: Nicholas Kassem <Nick.Kassem@eng.sun.com>
> > To: Jon Bosak <Jon.Bosak@eng.sun.com>;
> > <ebXML-Transport@lists.oasis-open.org>
> > Sent: Friday, April 07, 2000 10:01 PM
> > Subject: Re: [Fwd: Re[2]: Concern with basic ebXML TRP Syntax/Semantics]
> >
> >
> > > I believe we have agreed to support:
> > >
> > > 1) Pure XML for Message Headers
> > > 2) Pure XML for payloads
> > > 3) *optionally* non-XML payloads (because there is a large non-XML
> > legacy).
> > >
> > > The fact that the current packaging proposal recommends using
> > > multipart-related to bind the elements into a single message is simply
> > > pragmatic. IMO. We are proposing to use an existing Internet
> > standard. No
> > > application will ever have to see the outer wrapper (be it in MIME or
> > > whatever) - in the same way that one normally doesn't see TCP headers
or
> > > "200 OK" from HTTP. Most importantly applications will see pure XML if
> > > that's in the message payload. If this approach offends the
> > sensibilities
> > > of some then we should go out of our way to solicit counter proposals
-
> > and
> > > review them openly.
> > >
> > > Jon, are we completely off-track here ?
> > >
> > > Regards,
> > > Nick
> > >
> > >
> > > At 01:30 PM 4/7/2000 -0400, Christopher Ferris wrote:
> > >
> > >
> > > >-------- 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.
> > >
> > >
> >
> >
Jon,
An example of what I said about some folks in the TRP who believe that XML
packaging is possible.
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"
____________________Forward Header_____________________
Subject: RE: [Fwd: Re[2]: Concern with basic ebXML TRP Syntax/Semanti
Author: Ravi Manikundalam <ravima@microsoft.com>
Date: 4/10/00 7:57 PM
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC