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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

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


Subject: Re: [ebxml-msg] Status of Messaging spec vote


All,

We at Sun previously contacted Phil Griffin to ask for a clarification of
his comment.  Quoting from an email in that discussion:

| I'm not entirely certain ebXML Messaging prevents use of ASN.1 in
| the ways Phil would like.  The specification is entirely payload
| agnostic and goes so far as to recommend the SOAP Body not be used
| to contain the application content.  No requirement for an XML
| Schema description of the payload or payloads exists.  In this
| respect, the existing specification remains schema independent.
|
| If he would like to utilize ASN.1 to validate, encode and sign the
| message header itself, he's correct that he's out of luck.  We had
| to choose a single technology because of the need to identify in
| the message its relevant schema.  I don't understand a way to make
| this aspect of ebXML Messaging schema independent.  Yes, we could
| have defined the concepts at a higher level and bound them to SOAP
| but the additional layer wouldn't have helped with
| interoperability concerns.  If this is Phil's primary area of
| concern, he should vote "no" on the SOAP 1.2 specification at the
| W3C.

Phil, would you care to comment further for the benefit of this group?  I
may not have been clear in my comments above: ebXML Messaging defines a
wire protocol for carrying some semantic / descriptive information between
two systems.  That wire protocol is schema dependent to the extent it
leverages the SOAP protocol.  That extent does not cover the associated
business documents or (more generically) payload content.  ebXML Messaging
is completely payload agnostic and schema independent for those payloads.

thanx,
    doug

"Karl F. Best" wrote:

> Messaging TC:
>
> Voting for consideration of the ebXML Messaging Committee
> Specification as an OASIS Standard ended yesterday. The vote did reach
> quorum, and a vast majority of votes were affirmative.
>
> There was, however, one negative vote. (Please see
> http://lists.oasis-open.org/archives/tc-voting/200207/msg00003.html)
> As defined by the OASIS TC Process
> (http://www.oasis-open.org/committees/process.shtml#sec2) if there are
> any negative votes the TC must decide how to handle this:
>
> "...if negative votes amounting to less than 10 percent of the voting
> membership have been cast, the negative votes and accompanying
> comments, if any, shall be forwarded to the originating TC for
> consideration. After notification of the results, the TC shall have 30
> days to take one of the following actions by resolution: (x) request
> OASIS to approve the specification as submitted despite the negative
> votes, or (y) withdraw the submission entirely, or (z) submit an
> amended specification, in which case the amended submission shall be
> considered as if it were a new submission, except that information
> regarding previous votes and any disposition of comments received in
> previous votes shall accompany the amended submission."
>
> The TC must now decide, within 30 days, which of these options to
> select.
>
> </karl>
> =================================================================
> Karl F. Best
> OASIS - Director, Technical Operations
> +1 978.667.5115 x206
> karl.best@oasis-open.org  http://www.oasis-open.org
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>



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


Powered by eList eXpress LLC