Review of WS-Context version 0.3

["Murray, Bryan P." <bryan.murray@hp.com>]

This is a review of the latest version of WS-Context

The table of contents contains page numbers, but the remainder of the
document does not have page numbers. I propose we either remove the page
numbers from the table of contents or add page numbers to every page.

Section 1.1, first para: The text talks about both synchronous and
asynchronous messaging, however the normative WSDL seems to provide only
an asynchronous interface. I suggest changing the latter part of the
sentence to: "they may use synchronous or asynchronous messaging
passing". I think the use of "RPC-style" here confuses the issue. Along
the same lines is the first sentence in the 3rd paragraph which implies
that request/response is not a message interaction. Again I suggest
rewording to: "support both synchronous and asynchronous interactions".

Are the bindings in the WSDL considered normative also? Does this mean
that if I am using SOAP 1.1 over HTTP that I must use the binding in the
WS-Context WSDL document? Are there conditions under which I am allowed
to create a different binding for SOAP 1.1 over HTTP?

Section 1.1, last para: the parenthetical phrase in the last sentence
implies that the WSDL is not normative. Perhaps this should be
clarified.

Section 1.2, first para: The use of "synchronous" here is confusing.
Maybe "one-way" for the first use of synchronous and "asynchronous" for
the second use of synchronous would help. There is also a reference here
to other binding styles. Again an example would help a lot and some text
indicating that either all or part of the WSDL is normative and how an
implementer can provide other bindings and still be compliant with this
spec.

Section 1.3, 2nd para: The last sentence contains "ServiceRef".  Figure
1 and following text indicate this should be "service-ref".

Section 1.3: the 2 paragraphs above figure 2 seem to be redundant (1
XML, 1 text). I suggest removing both.

Section 2: the XML element
  <xs:element ref="service-ref" type="xs:anyURI" ...>
should not contain the attribute "type".

context-identifier: are there any uniqueness requirements for this
field? If so, what are they: unique to the ContextService, unique to the
machine, unique to the local network segment, unique to the enterprise,
or globally unique?

context-service: fields that are URIs and cannot be dereferenced usually
have either a set of valid values, or rules to determine a valid value.
How is a value for this field chosen? What are the uniqueness
requirements?

type (bullet 3): I almost missed what this bullet was about. Similar
questions for this field as for context-service.

mustPropogate and mustUnderstand attributes are not described anywhere.

Section 2, 4th bullet: The last sentence implies that the context-url
may be dereferenced. Does this mean that if the URI protocol is http,
that an HTTP GET can be used to read the context?

Section 2, bullet about timeout value: after the semicolon there is an
extra "the". What is the expected behavior is there is no timeout
attribute - it is listed as optional?

Following parenthesized statements: What happens if there is no issuing
authority (context-service is optional)?

Section 2, last bullet: change "extensibility element of type xsd:Any"
to "extensibility xsd:any element". It is incorrect the way it is
currently written.

Section 2.1, example: mustUnderstand should be moved to the context
element, not the SOAP Header element. I think the namespace for
WS-Context should be stated somewhere in the text of the spec rather
than first seeing it in this example. There is an activity-service
element that is used in 2 places which is not described in the text.

Section 3: I have covered this section in a separate email.

Section 5.1: When I read this I wrote a note that the operations that
can cause these transitions should be listed here. Later I found the
diagram at the end of section 5. I think this diagram or all of section
5.2.1 might make more sense in section 5.1 than in section 5.2. I'm not
sure - I could go either way.

Section 5.2, first bullet under WSDL: there is 2 occurrences of
"complete".

Section 5.2, para above "begin": it says that an endpoint address is
exchanged during each operation. However, there is no description as to
how this is done. The WSDL does not contain any clues to this either.
Additional text is needed here. The same text should probably also be in
section 3.

"complete": the second para starts with "An", it should probably be "A".

Section 5.2.1: change "various messages exchanges" to "various message
exchanges". Again there needs to be an explanation for how to do what is
described in the last sentence.