← Prev in month ← Prev in thread
Next in thread → Next in month →

New issues July 7-14

From
Marc Goodner <>
Date
2005-07-14T20:07:03+00:00
ID
Thread
New issues July 7-14
Below are the new issues raised since the July 7th TC call
and the July 14th TC call.

Title: typo in expires P0S

Title:  typo in Interop scenario 3.2 example 

Title: anonymous acksTo

Title: Document Names 

Title: Required Artifact Metadata 

Title: Document Identifiers

Title: XML Namespace URIs 

 

 

Title: typo in expires
P0S 

Description: per the schema spec a
zero second duration needs to have the "T" designator - so it should
be PT0S not P0S. 

Justification: align with schema
spec ( http://www.w3.org/TR/xmlschema-2/#duration ) 

Target: core 

Proposal: simple search and
replace of P0S with PT0S

http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200507/msg00046.html

 

 

Title:  typo in Interop
scenario 3.2 example 

Clarification - the document is Interop Scenario 3, not the
main spec.  

The section is at the end of 3.2

 

This one is an easy fix - the first example of a message had
one visible 

error - an extra white space after the two "--" of
the comment.

 

|<!-- BEGIN: 128-bit key K encrypted using public key of
SERVICE --

 >|

http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200507/msg00061.html

 

 

Title: anonymous acksTo

http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200507/msg00066.html

 

Title: Max message
number in policy 

Description: define a policy
assertion that defines the highest message number the RM destination will
accept. 

Justification: without knowing in advance what the highest message number is
the RM source may exceed it, causing the entire sequence to be terminated -
when it may have been able to start a 2nd sequence to continue its work.
 By allowing the RM source the option of terminating the sequence
gracefully it can still deliver lost messages for the original sequence.
 As it stands now, if the sequence is terminated the lost messages will
not be resent. 

Target: RM policy spec 

Proposal: Define: 

/wsrm:RMAssertion/wsrm:MaxMessageNumber 

/wsrm:RMAssertion/wsrm:MaxMessageNumber@number - unsigned long

 

http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200507/msg00073.html

 

Title: Document Names 

Description: Should the
“names” of the normative documents remain the same as the
submission documents or should they be changed? This issue applies to both
WS-ReliableMessaging and WS-RM Policy.

Justification: The
“name” of a document effects a number of things such as the
document identifier, URIs etc.

Target: core, policy

Type: editorial

Proposal: Preserve the name
of the documents as submitted. Changing the names would increase confusion
(already at a high level) around “OASIS and RM” and result in extra
effort. There does not seem to be any reasons for changing the names forcefull
enough to override these concerns. Therefore the names of the normative
documents should be “Web Services Reliable Messaging Protocol
(WS-ReliableMessaging)” and “Web Services Reliable Messaging Policy
Assertion (WS-RM Policy)”

 

http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200507/msg00090.html

 

Title: Required Artifact
Metadata 

Description: OASIS guidelines
(http://www.oasis-open.org/committees/download.php/13344/ArtifactIdentificationRequirements-v1.0-wd-15.pdf)
require that the artifacts (documents, schemas, etc.) produced by a TC should
have a minimum set of of metadata that describes these artifacts.

Justification: OASIS
requirement.

Target: core, policy

Type: editorial

Proposal: We propose the
following values for each specification:

WS-ReliableMessaging:

artifactName: TBD

tc: TBD

product: wsreliablemessaging

productVersion: 01

artifactType: spec

stage: wd

descriptiveName: Web Services Reliable Messaging Protocol Specification

WS-RM Policy:

artifactName: TBD

tc: TBD

product: wsrmpolicy

productVersion: 01

artifactType: spec

stage: wd

descriptiveName: Web Services Reliable Messaging Policy
Assertion Specification

Note that the “product names” of these two
artifacts differ.

 

http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200507/msg00091.html

 

Title: Document
Identifiers

Description: The artifacts
(documents, schemas, etc.) produced by the WS-RX must be uniquely identified.
We need to decide on the identifiers for WS-ReliableMessaging and WS-RM Policy.

Justification: Self-evident.

Target: core, policy

Type: editorial

Proposal: According to the
OASIS guidelines and in light of the proposed artifact metadata, the documents
should currently be identified as:

wsreliablemessaging-01-spec-wd-01.*

wsrmpolicy-01-spec-wd-01.*

Note that some identifiers may have the final sub-version
removed. The “*” indicates that these documents may be formatted in
either HTML (.html) or PDF (.pdf).

 

http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200507/msg00092.html

 

Title: XML Namespace
URIs 

Description: We need to decide
upon the normative XML namespace URIs that must be used by implementations of
these specifications.

Justification:
Self-evident.

Target: all

Type: editorial

Proposal: The namespace
URIs for WS-RX-defined schemas should be URLs that resolve to RDDL documents
that provide information about the schema as well as links to the corresponding
specification(s). Per OASIS guidelines, the RDDL documents must be hosted by
OASIS. Therefore the exact URL values will need to be co-ordinated with OASIS
but, in general, they should look something like the following:

xmlns:wsrm=”http://www.oasis-open.org/committees/ws-rx/wsreliablemessaging-200507.html”

xmlns:wsrmp=”http://www.oasis-open.org/committees/ws-rx/wsrmpolicy-200507.html”

Note that the “200507” in the URL is represents
the schema version as a date (July, 2005).

 

http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200507/msg00093.html
← Prev in month ← Prev in thread
Next in thread → Next in month →