OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-transport message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: [Fwd: Re[2]: Concern with basic ebXML TRP Syntax/Semantics]




Ravi Manikundalam wrote:

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

Ravi,

I am not sure I understand. Name spaces can be used when DTDs are used also.
Could you address how the following benefits that I listed can be realized with
schemas employing name spaces.

Thanks.

> -----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
> > > (&amp &lt 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.
> > > >
> > > >
> > >
> > >



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC