RE: [ebxml-cppa] Packaging question

[Dale Moberg <dmoberg@cyclonecommerce.com>]

Arvola writes:

"The Packaging element indirectly (through CompositeList, Composite, and
Encapsulation) references one or more SimplePart elements. The
NamespaceSupported element under SimplePart can occur 0 or more times to
identify the namespaces associated with the corresponding body part.

"Instead of defining a distinct Packaging to be used with each
requesting or responding business activity, is it possible to define a
generic Packaging that can be used for multiple requesting and/or
responding business activities?"

Dale> I think this is a good opportunity for trying to 
clarify our representation of Namespace related capabilities and
agreements.

The motivation for having Namespaces under Packaging
was partly that the MIME types "application/xml" and "text/xml" 
did not provide much detailed information 
about the processing requirements/capabilities or agreements.

In addition, because Packaging pertains to each DeliveryChannel 
under an ActionBinding, it has a wider scope than the NamespaceSupported
element under DocExchange (which is per DeliveryChannel). 

Arvola points out that when using BPSS, there is an implicit
NamespaceSupported
for each Request or Response. There is little need to repeat that
information
in the Packaging. 

I agree. However, the BPSS Namespace indications won't indicate
extensions like XMLDsig and XMLEncryption (which I think of as ones
normally
announced within Packaging). 

On the other hand, we could put these functions
under DocExchange/ebXML[Receiver|Sender]Binding/NamespaceSupporte
(repeating
for each channel) and also being restricted to ebXMLXXXBinding.

Therefore, I still think there is a place for
NamespaceSupported element under Packaging. Would it be
possible to state that this element is used when 
some indicator is needed for processing at lower 
middleware layers?

The namespaces for XMLDsig, ebMS, SOAP, XMLP, 
and XML Encryption might be ones that influence MSH and 
lower level middleware components; 
the actual business document namespaces 
would probably not be relevant, unless some
extension to the BPSS announced Namespaces was used. 

I think we have not yet clarified these nuances,
and we have not formed guidelines on usage.

================

Here are the excerpts that we now have that we can edit.
I hope to post some possible additions
to this text to maybe clarify why and when it is
usefu to use the namespaceSupported element in
various places. If you have some specific thoughts, please
post them and I will try to roll them up into
the revised text.

[DocExchange somewhere]
zero or more NamespaceSupported elements that 
identify any namespace extensions supported by the messaging service
implementation

[DocExchange]
The NamespaceSupported element identifies the namespaces supported by
the messaging service implementation. Examples are Security Services
Markup Language[S2ML] and Transaction Authority Markup Language[XAML].
For example, support for the S2ML namespace would be defined as follows:
<tp:NamespaceSupported    tp:location="http://www.s2ml.org/s2ml.xsd" 
    tp:version="0.8">
    http://www.s2ml.org/s2ml
</tp:NamespaceSupported>

In addition, the NamespaceSupported element is used 
to identify the namespaces associated with the message 
body parts (see Section 8.5) that together define the 
Packaging of action messages.

[SimplePart]
The SimplePart element can have zero or more NamespaceSupported
elements. 
Each of these identifies any namespace supported for the XML packaged in

the parent simple body part. When multiple NamespaceSupported elements 
are used within a SimplePart element, the first NamespaceSupported
element 
identifies the schema for the SimplePart while the remaining
NamespaceSupported elements represent namespaces that are imported by
that schema. 

 NOTE: The explicit identification of imported namespaces is OPTIONAL.
Thus, the CPP and CPA examples in Appendix A  and Appendix B  explicitly
identify the ebXML Messaging Service namespace but omit the SOAP
envelope and XML Digital Signature namespaces that are imported into the
schema for the ebXML Messaging Service namespace.

The same SimplePart element MAY be referenced from (i.e., reused in) 
multiple Packaging elements.
 
=========================
Arvola> Can we interpret a Packaging which indirectly references only a
single
SimplePart and which does not have a NamespaceSupported sub-element as
indicating that the schema associated with the BusinessDocument defined
at
the BPSS level is to be used?

Dale>OK, let us state this, and add that any Namespace extensions (not
found
in BPSS instance) would be put here.

Arvola> One feedback I got from my implementation team is that it seems
rather
cumbersome to create all the necessary Packaging elements, one for each
action (corresponding to a requesting or responding business activity).
It
would be useful to have a shortcut for the default case (when arbitrary
overrides are not necessary).

Dale> I think this is possible already unless some special indication is
needed (a new XMLDsig namespace different from that reference in ebMS
for example).
I think NamespaceSupported needs to be used for special cases to call
out
something non-standard...