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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-cppa message

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


Subject: [ebxml-cppa] Rewrite of the NamespaceSupported text passages.


Title:

Arvola this week raised a number of good questions
about the rationale for the NamespaceSupported elements.

I still think they can be useful even if BPSS or some other
similar BP description language supplies
namespace information in its documents

Here is an attempt to rework the passages.

Please help polish these to arrive at clear usage guidelines!

[Incorporates a change Arvola sent Thursday PM.]

 
Dale Moberg



[DocExchange updates]

The NamespaceSupported element identifies the namespaces supported by
the messaging service implementation. While the NamespaceSupported
element can be used to list the namespaces that could be expected
to be used during document exchange, the motivation is primarily
for extensions, version variants, and other enhancements that
might not be expected, or have only recently emerged into use.

For example, support for Security Assertion Markup Language[SAML]
would be defined as follows:

<tp:NamespaceSupported
tp:location="http://www.oasis-open.org/committees/security/docs/draft-sstc-s
chema-assertion-27.xsd"    tp:version="1.0">
http://www.oasis-open.org/committees/security/docs/draft-sstc-schema-assertion-27.xsd
</tp:NamespaceSupported>

In addition, the NamespaceSupported element can be used
to identify the namespaces associated with the message
body parts (see Section 8.5), and especially when
these Namespaces are not implicitly indicated through
parts of the ProcessSpecification or when they indicate
extensions of namespaces for payload body parts.

[SimplePart]
The SimplePart element can have zero or more NamespaceSupported
elements.

Each of these identifies any namespace supported for the XML
that is packaged in the parent simple body part.

The context of Packaging can very easily render
it pointless to list all the namespaces used in SimpleParts. For
example, when defining the SimplePart for a SOAP envelope, as
part of an ebXML Message, it is not necessary to list all
the namespaces. If, however, any unusual extensions, new versions,
or unusual security extensions are present, it is useful to
announce these departures explicitly in the packaging.

It is not, however, incorrect to list all namespaces used in
a SimplePart, even where these Namespaces have been mandated
by a given Messaging protocol. By convention, when a full
listing of namespaces is supplied within a SimplePart element,
the first NamespaceSupported element identifies the schema
for the SimplePart while subsequent
NamespaceSupported elements represent namespaces that are imported by
that schema. Any additional NamespaceSupported elements indicate
extensions.

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 can be referenced from (i.e., reused in)
multiple Packaging elements.



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


Powered by eList eXpress LLC