[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [ebXML-dev] CPPA Message Packaging
Hi again, I have another question regarding the CPP Packaging element. In the CPPA schema, it specifies there is one and only one Packaging element. However, in the CPPA specification document, it states that: The child elements of the Packaging element are ProcessingCapabilities, SimplePart, and CompositeList. This set of elements MAY appear one or more times as a child of each Packaging element in a CPP and SHALL appear once as a child of each Packaging element in a CPA. " . . . each Packaging element . . ." - this is stating that there are multiple Packaging elements within a CPP, is it not? This makes sense to me; I cannot understand how there can only be one Packaging element, and if there is, why we reference it (when there is only one to choose from) in the Service Binding of the Collaboration Role. Can anyone clarify this for me? Thanks, Laura McLean -----Original Message----- From: Dale Moberg [mailto:dmoberg@cyclonecommerce.com] Sent: Friday, January 04, 2002 11:21 AM To: laura.mclean@briyante.com; ebxml-dev@lists.ebxml.org Subject: RE: [ebxml-dev] CPPA Message Packaging OK, here is a short example using a standard use case (which I am uncertain is actually used anywhere!) The normal ebXML Request message has a MIME structure that consists of a "multipart/related" MIME entity that in turn consists of two MIME entities: a SOAP envelope (text/xml) and a payload (with a MIME type typically of text/xml, application/xml, or some other xml flavored MIME type, such as application/something+xml.) An extension might be to add a third MIME entity within the multipart/related of (making this up) application/cadcam-drawing. This extension would be used in an industry in which a Purchase Order might be accompanied by a machine-readable specification for the items(s) being purchased. A CPA template or CPP for this "extension" could then indicate how this PO+cadcam request was packaged. The MIME packaging procedure is inherently extensible in this way. MIME specifies a default processing mode for any multipart/subtypes, which is to just fall back to multipart/mixed handling, which then just processes each bodypart in accordance with its MIME handler, or with the default handler (a handler that might just store the bodypart in a file). The multipart/related type is, however, one in which some richer semantics for processing is indicated. How do we tell whether this semantics is supported or not? We could call up the other side once we knew all the details! Or, better/faster/cheaper, we could rely on a more automated process to set up this richer connection when possible. That is one thing CPPA related approaches are trying to do. If you are actually interested in XML text of a Packaging element with extensions beyond those of ebXML messaging, you can find some (a little outdated) in the ebXML Technical Architecture Security Risk support, in one of the appendices. Dale Moberg -----Original Message----- From: Laura McLean [mailto:laura.mclean@briyante.com] Sent: Friday, January 04, 2002 11:44 AM To: Dale Moberg; ebxml-dev@lists.ebxml.org Subject: RE: [ebxml-dev] CPPA Message Packaging Dale, Thanks alot for your help. I have a couple more questions based on your response. Can you define "extensions" and "MIME structure", what do you mean and what's the difference between the two? Also, can you give me an example where the CPA specifies extensions? Thanks again, Laura McLean -----Original Message----- From: Dale Moberg [mailto:dmoberg@cyclonecommerce.com] Sent: January 4, 2002 10:02 AM To: laura.mclean@briyante.com; ebxml-dev@lists.ebxml.org Subject: RE: [ebxml-dev] CPPA Message Packaging Here is a short start: The CPPA notation provides a way to document what packaging will be used in the implementation of a business process. The MIME structures of the messages are described. The Messaging group specifies what the ebXML packages are and what are the ways to extend or combine these packaging options. The Messaging specification describes specific MIME structures for packaging using the "multipart/related" type. Because extensions are possible, the CPPA group allows parties to disclose to other parties or discover from other parties the extensions they support. They then agree on the actual extensions to be used, if any. Even when basic ebXML packaging is used, there are options in how messages return information. For example, when using HTTP, one message may return messaging level signals "synchronously", while another message may independently and "asynchronously" return business signals and business response. The possible combinations and options supported in this area can be documented in CPPs and the ones to be used can be agreed to in a CPA for the business process of interest. -----Original Message----- From: Laura McLean [mailto:laura.mclean@briyante.com] Sent: Friday, January 04, 2002 10:31 AM To: ebxml-dev@lists.ebxml.org Subject: [ebxml-dev] CPPA Message Packaging Both the ebXML CPPA and TRP specifications use message packaging. I am not sure what the purpose of the packaging in the CPP/CPA is, and what the relationship between the CPP/CPA and TRP packaging is. Can anyone clear this up for me? Thanks for your help, Laura McLean ---------------------------------------------------------------- The ebxml-dev list is sponsored by OASIS. To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.ebxml.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC