Re: [ws-rx-editors] Groups - WS-RX_CS-01_DirStructured.zip uploaded

[Robin Cover <robin@oasis-open.org>]

On Fri, 2 Mar 2007, Paul Fremantle wrote:

> Robin
>
> I believe we have a single specification as defined in your discussion.
>
> Here is an updated draft. Does that seem clearer to you?
>
> -------------------------------------------------------
>
> Submission document for the Web Services ReliableMessaging Specification 1.1

Thanks, Paul.  I'll defer to Mary McRae on all matters of interpretation.

That said, my observations:

1. The title "Web Services ReliableMessaging Specification 1.1" as a
   "single title" seems plausible enough if the community thinks of
   the tri-partite work as "The Web Services ReliableMessaging Specification",
   using principal spec title (modulo 'Reliable Messaging' vs 'ReliableMessaging')
   as the collective work identifier

2. I note the specification title page titles as:

Web Services Reliable Messaging (WS-ReliableMessaging) Version 1.1
Web Services ReliableMessaging Policy Assertion (WS-RM Policy) Version 1.1
Web Services Make Connection (WS-MakeConnection) Version 1.0

* unsure if "Version 1.0" is relevant to the TC Process rule [single] version number
* not clear why WSRMP title has 'ReliableMessaging' vs 'Reliable Messaging'

3. I noted the following in the trademarks statement (for WSRMP):

   "WS-ReliableMessaging Policy, WS-ReliableMessaging, WSRMP, WSRM, WS-RX"
    are trademarks of OASIS...

* name 'WS-ReliableMessaging Policy' does not match title words in WSRMP
  (may not matter)

4. My only reason for raising the question is to possibly avoid any
   expectation mis-matches; Mary can clarify. In some cases (past),
   it appears that TCs have approved a collection of specs at the
   CD/PR/CS level without paying much attention to 2.18's words:

   * single specification name
   * [single] version number

   Then, when the TC wants to ballot the material as a single specification
   for approval as an for OASIS Standard (in ONE ballot, using one
   submission package), they are met with TC Administration enforcement
   of the rules: "single name, same version identifier"

   I think this happened recently with the WS-SX specifications:

   Announcement:
   http://lists.oasis-open.org/archives/tc-announce/200702/msg00001.html
   WS-Trust 1.3 and WS-SecureConversation 1.3 Submitted for OASIS Standard

   then, the specs needed to be balloted separately:

   Balloting for OASIS Standard - WS-SecureConversation v1.3
   http://lists.oasis-open.org/archives/tc-announce/200702/msg00006.html
   Balloting for OASIS Standard - WS-Trust 1.3
   http://lists.oasis-open.org/archives/tc-announce/200702/msg00008.html

5. Quite apart from any of the WS-RX TC work, it seems to me that
   the TC Process should be clearer about the significance of the
   rule requiring a "single specification name."  For example, if that
   "single specification name" does not appear on all of the parts
   of the "multi-part specification", what's the point?  How
   would we know, at a glance, that the "Web Services Make Connection
   (WS-MakeConnection) Version 1.0" specification is "part of" the
   "Web Services ReliableMessaging Specification 1.1" standard --
   say, by looking at the WSMC spec title page? The WSMC 'Abstract'
   does not mention the "single specification name" or any of the
   other two parts.

   In some cases, I think I've seen the "single specification name"
   used -- by anyone -- ONLY in the OS submission request and
   ballot announcement: if so, what's the point?  I'm on the
   Board Process Committee, so I guess I can ask there for
   some clarification.  ** To be clear, the above is not meant
   to imply criticism of the WS-RX TC specs as written; it
   questions the relevance of "single specification name" as
   worded in the TC Process and as implemented by TCs broadly.

Anyway... congrats on this TC's great work.  I'm proud to help get
it published!

Robin Cover

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

>
>
> (a) Links to the approved Committee Specification in the TC?s document
> repository, and any appropriate supplemental documentation for the
> specification, both of which must be written using the OASIS templates.
> The specification may not have been changed between its approval as a
> Committee Specification and its submission to OASIS for consideration as
> an OASIS Standard, except for the changes on the title page and running
> footer noting the approval status and date.
>
>
> Web Services ReliableMessaging
> PDF - http://docs.oasis-open.org/ws-rx/wsrm/v1.1/wsrm.pdf
> HTML - http://docs.oasis-open.org/ws-rx/wsrm/v1.1/wsrm.html
> Schema -
> http://docs.oasis-open.org/ws-rx/wsrm/200702/wsrm-1.1-schema-200702.xsd
> WSDL -
> http://docs.oasis-open.org/ws-rx/wsrm/200702/wsdl/wsrm-1.1-wsdl-200702.wsdl
>
> Web Services ReliableMessaging Policy
> PDF - http://docs.oasis-open.org/ws-rx/wsrmp/v1.1/wsrmp.pdf
> HTML - http://docs.oasis-open.org/ws-rx/wsrmp/v1.1/wsrmp.html
> Schema -
> http://docs.oasis-open.org/ws-rx/wsrmp/200702/wsrmp-1.1-schema-200702.xsd
>
> Web Services MakeConnection
> PDF - http://docs.oasis-open.org/ws-rx/wsmc/v1.0/wsmc.pdf
> HTML - http://docs.oasis-open.org/ws-rx/wsmc/v1.0/wsmc.html
> SCHEMA -
> http://docs.oasis-open.org/ws-rx/wsmc/200702/wsmc-1.0-schema-200702.xsd
> WSDL -
> http://docs.oasis-open.org/ws-rx/wsmc/200702/wsdl/wsmc-1.0-wsdl-200702.wsdl
>
> (b) The editable version of all files that are part of the Committee
> Specification;
>
> http://docs.oasis-open.org/ws-rx/wsrm/v1.1/wsrm.doc
> http://docs.oasis-open.org/ws-rx/wsrmp/v1.1/wsrmp.doc
> http://docs.oasis-open.org/ws-rx/wsmc/v1.0/wsmc.doc
>
> (c) Certification by the TC that all schema and XML instances included
> in the specification, whether by inclusion or reference, including
> fragments of such, are well formed, and that all expressions are valid;
>
> All schema and XML instances included in the specification are well
> formed and all expressions are valid.
>
> (d) A clear English-language summary of the specification;
>
> The WS-ReliableMessaging 1.1 specification consists of multiple parts.
>
> The core WS-ReliableMessaging 1.1 document defines a protocol for
> reliable message exchange between two Web services, even in the presence
> of network or system failures. For example, the protocol can ensure the
> resending of messages that have been lost, and can ensure that duplicate
> messages are not delivered. The protocol allows Web service nodes to
> implement a variety of delivery assurances, including at most once, at
> least once, exactly once and in-order delivery of messages. The protocol
> fundamentally defines a one-way reliable channel (known as a Sequence),
> but also includes mechanisms to optimize the creation of two-way
> reliable exchanges.
> The protocol is designed to compose with other relevant standards such
> as WS-Security and WS-SecureConversation. The protocol allows developers
> to add reliable delivery of messages to their applications on a variety
> of platforms, including Java and .NET.
>
> The WS-ReliableMessaging Policy 1.1 document defines an XML policy
> language that enables Web services to advertise their support for the
> WS-ReliableMessaging specification. The specification is designed for
> use with the WS-Policy Framework. The language aids the interoperability
> of nodes that support WS-ReliableMessaging by publishing their support
> and requirements. For example, an endpoint may use this specification to
> indicate that it requires that the reliable message protocol to be
> secured using transport level security. WS-ReliableMessaging Policy is
> designed to be used with other policy languages, such as WS-Security
> Policy, in the scope of the WS-Policy Framework.
>
> The WS-MakeConnection 1.0 document defines a protocol that can be
> used to allow two-way communications when only a transport specific
> back-channel (such as the HTTP response mechanism) is available. For
> example, when used with the WS-ReliableMessaging protocol,
> WS-MakeConnection allows a client to establish a two-way reliable
> message exchange even in the presence of firewalls and network address
> translation that would prevent the server from initiating connections to
> the client. WS-MakeConnection can be bound to a specific
> WS-ReliableMessaging sequence, or use a generic URI syntax to define the
> logical set of messages that should be transferred.
>
> (e) A statement regarding the relationship of this specification to
> similar work of other OASIS TCs or other standards developing organizations;
>
> -- The OASIS WS-Reliable Messaging (WSRM) TC also defines a reliable
> messaging specification for Web services. The WS-RX TC and
> WS-ReliableMessaging specification focusses on creating a specification
> which composes with other specifications, in particular the
> WS-Addressing, WS-Security and WS-SecureConversation, and WS-Policy
> Framework specifications.
>
> (f) Certification by at least three OASIS member organizations that they
> are successfully using the specification;
>
> http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200702/msg00068.html
> http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200702/msg00069.html
> http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200703/msg00000.html
> http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200703/msg00017.html
>
> (g) The beginning and ending dates of the public review(s), a pointer to
> the announcement of the public review(s), and a pointer to an account of
> each of the comments/issues raised during the public review period(s),
> along with its resolution;
>
> First Public Review: 24 August 2006 to 21 October 2006
> Second Public Review: 12 February 2007 to 27 February 2007
>
> Announcement of the first Public Review:
> http://lists.oasis-open.org/archives/tc-announce/200608/msg00005.html
>
> Announcement of the second Public Review:
> http://lists.oasis-open.org/archives/tc-announce/200702/msg00004.html
>
> Public Review Issue and Resolution Log:
> http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml
>
> (h) An account of and results of the voting to approve the specification
> as a Committee Specification, including the date of the ballot and a
> pointer to the ballot;
> TBD
>
> (i) An account of or pointer to votes and comments received in any
> earlier attempts to standardize substantially the same specification,
> together with the originating TC?s response to each comment;
>
> This is the first submission to the OASIS membership
>
> (j) A pointer to the publicly visible comments archive for the
> originating TC;
> http://lists.oasis-open.org/archives/ws-rx-comment/
>
>
> (k) A pointer to any minority reports submitted by one or more Members
> who did not vote in favor of approving the Committee Specification,
> which report may include statements regarding why the member voted
> against the specification or that the member believes that Substantive
> Changes were made which have not gone through public review; or
> certification by the Chair that no minority reports exist.
>
> There are no minority reports.
>
> ---------------------------------------------
>
> Robin Cover wrote:
> > ACK receipt.  I confess that I've not been tracking closely with
> > all your spec drafts, but I'll endeavor to look at this ZIP material
> > today.
> >
> > Also, in passing... I noted Paul Fremantle's "First draft of the submission package"
> > http://lists.oasis-open.org/archives/ws-rx-editors/200703/msg00008.html
> >
> > Please forgive me if the issue I call out has already been dealt with:
> >
> > The submission package outline appears to conform to
> >
> > "3.4 Approval of an OASIS Standard"
> > http://www.oasis-open.org/committees/process.php#3.4
> >
> > In this connection, I note the language of
> > "2.18 Specification Quality"
> > http://www.oasis-open.org/committees/process.php#2.18
> >
> > ===================================================================
> > "...
> > A specification may be composed of any number of files
> > of different types, though any such multi-part specification
> >
> > must have a single specification name and version number.
> >
> > Irrespective of the number and status of the constituent parts, the
> > specification as a whole must be approved by a single TC ballot.
> >
> > Any change made to a specification requires a new version or
> > revision number, except for changes made to the title page
> > and in the running footer noting the approval status and date,
> > which must be made after the approval of the specification.
> >
> > ===================================================================
> >
> > * single specification name
> > * [single] version number
> > * approved by a single TC ballot
> >
> > The provisional text for "First draft of the submission package"
> > could be seen as reflecting the TC's intent to make ONE submission,
> > since in section "(d)" I read:
> >
> > (d) A clear English-language summary of the specification;
> > [...]
> >
> > The WS-ReliableMessaging 1.1 specification...
> > The WS-ReliableMessaging Policy 1.1 specification
> > The WS-MakeConnection 1.0 specification
> >
> > That would be a "multi-part specification", I think.
> >
> > And so, if there is to be ONE submission for this material:
> >
> > 1) what is the "single specification name"?
> > 2) what is the single version number?
> >
> > In other words, as I understand the TC Process, if the WS-RX
> > TC wants to have the material submitted and balloted (at the
> > OASIS Member level, for OS) as a "specification" (singular),
> > it will have to be constructed to meet requirements "1)" and "2)".
> >
> > Of course, nothing said above is official: please see your
> > TC Staff Contact person for authoritative interpretations.
> >
> > I do know we've faced some expectation mis-matches on this point
> > in the past.
> >
> > Cheers,
> >
> > Robin
> >
> > ============
> >
> > On Fri, 2 Mar 2007 gilbert.pilz@bea.com wrote:
> >
> >> Here are the CS-01 files in their appropriate directory structure including
> > RDDLs. I've changed the links in the RDDL files to be relative, so you can
> > test the links before Robin actually deploys these.
> >> - the RDDL'er
> >
> >  -- Gilbert Pilz
> >
> > The document named WS-RX_CS-01_DirStructured.zip has been submitted by
> > Gilbert Pilz to the WS-RX Editors SC document repository.
> >
> > Document Description:
> > CS-01 files in the appropriate directory structure
> >
> > View Document Details:
> > http://www.oasis-open.org/apps/org/workgroup/ws-rx-editors/document.php?document_id=22686
> >
> > Download Document:
> > http://www.oasis-open.org/apps/org/workgroup/ws-rx-editors/download.php/22686/WS-RX_CS-01_DirStructured.zip
> >
> >
> > PLEASE NOTE:  If the above links do not work for you, your email application
> > may be breaking the link into two pieces.  You may be able to copy and paste
> > the entire link address into the address field of your web browser.
> >
> > -OASIS Open Administration
> >
>
> --
> Paul Fremantle
> VP/Technology and Partnerships, WSO2
> OASIS WS-RX TC Co-chair
>
> http://bloglines.com/blog/paulfremantle
> paul@wso2.com
> (646) 290 8050
>
> "Oxygenating the Web Service Platform", www.wso2.com
>
>