Re: [ws-caf] Review of WS-Context version 0.3

["Mark Little" <mark.little@arjuna.com>]

Bryan, any issues that I think are non-editorial I'll register with the
issue system on your behalf.

Mark.

----
Mark Little,
Chief Architect, Transactions,
Arjuna Technologies Ltd.

www.arjuna.com

----- Original Message -----
From: "Murray, Bryan P." <bryan.murray@hp.com>
To: <ws-caf@lists.oasis-open.org>
Sent: Thursday, June 24, 2004 1:44 AM
Subject: [ws-caf] Review of WS-Context version 0.3


> 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.
>