[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-caf] Review of WS-Context version 0.3
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. >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]