RE: [ws-caf] Comments on 0.5 Draft

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

Following are my comments on the latest draft of WS-Context. I did not
look over the xsd and wsdl in detail.

Bryan


- Namespace has already been discussed. Need to change in spec, xsd, and
wsdl.

- Contradicting statements???
	Section 2.1: "... a normative WSDL binding is provided by
default in this
		specification."
	Section 2.2: "Where WSDL is used in this specification it uses
one-way messages
		with callbacks. This is prescriptive."
	Section 2.2: "Other binding styles are possible, although they
may have different
		acknowledgment styles and delivery mechanisms."
	The first 2 statements seem to disagree with the third
statement. Can a service
	describe itself in a WSDL document using a request/response or
some other
	interaction style and still be conformant with the spec? What
are the requirements
	on such a description (e.g. how does one describe where
responses will be sent)?

- Figure 2 should be made gray just as figure 1.

- Why can't WS-Context use the same namespace/type/element that was
defined by WSRM
  for a reference container? My understanding is that WSRM went out of
their way to
  put this definition in a separate namespace so it could be reused. If
we are going
  to define this type/element in WS-Context namespace and we change
reference-scheme
  to optional as suggested by Martin we need to explain what the default
is or how this
  should be interpretted if there is no scheme present. In some later
examples it
  appears as if the default is a URI, but this is not stated in the
text.

- The sentence under figure 3 sounds like the client can enforce the
addressing schemes
  to be understood by the service. This should be reworded to say
something like "a
  service receiving a service-ref element containing a reference-scheme
it does not
  understand MUST generate the XXX fault".

- Section 3, 1st sentence: This statement makes it sound like context is
only passed
  in SOAP headers. There are several messages which have context in the
SOAP body so
  this statement should be reworded.

- Section 3, context-service: If the context-service must not be
dereferenced, why is
  its type a ServiceRefType? The context-identifier is already unique,
so how does the
  context-service help in making this context unique?

- Section 3, timeout bullet: extra 'the' after semi-colon.

- Section 3, 2nd to last para: "If context-manager is dereferenced" -
what does it mean
  to dereference this element? It could be an HTTP GET, a SOAP request,
or ...

- Section 3.2, last sentence before example: The text makes it sound
like there are
  many header blocks and many context blocks. It's a little confusing
for an example
  having only 1 header block which is a context.

- Section 3.2, example: extra '=' on soap:Header element.

- Section 3.2, example: attribute mustUnderstand should be on context
element and not
  the soap:Header element.

- Section 5.2, sentence above begin: "The UserCTXService endpoint
address is exchanged
  during each operation in order to allow the Context Service to return
the result of
  the invocation." There is no description in either text, xsd, or wsdl
indicating how
  or where this address is located in a message. I assume this address
is passed in an
  element of type ServiceRefType, but it does not say. Is it expected
that the address
  be passed in a SOAP header? In order to provide for interoperable
implementations
  we need to say how the address is passed.

- Section 5.2, begin, para about timeout: "... Completed by the time the
timeout second
  elapse ...". I think an 's' should be added after second.

- Section 5.3, complete: "A Context Service implementation MAY impose
restrictions on
  which Web services can terminate an activity ...". How does the
Context Service impose
  these restrictions. There is no section on security even if it just
says there are
  a number of specs that may be used to secure the web service message
exchanges
  described in this specification.

- Section 3, setTimeout, 4th line: change associate to associated.


What should a service do if it receives a context having insufficient
information and
not having a context-manager field?

What does the namespace attribute mean on StatusType?



-----Original Message-----
From: Martin Chapman [mailto:martin.chapman@oracle.com] 
Sent: Tuesday, August 24, 2004 9:36 AM
To: ws-caf@lists.oasis-open.org
Subject: [ws-caf] Comments on 0.5 Draft

1. Section 2.3, Figure 1 and paragraph following:

To be consistent with ws-rm, the reference-scheme attribute should be
optional, not required.

2. section 3 after figure 4, 4th bullet.
Currently reads:

	An OPTIONAL service to get data associated with a
context-identifier that resolves to a
	reference to a Context Manager Web service.

Should this be
	An OPTIONAL service reference
?

3. section 3.1 3rd para.

Currently reads:

	A context is associated with one and only one activity;
"compound" activity contexts do not
	exist.

Even though nesting in mention 2 paras after, should we state here that
nested activities are ok? e.g 

 	A context is associated with one and only one activity;
"compound" activity contexts do not
	exist, although nested activities are permitted.

(the problem here is that nesting is a vlid compounding mechanism, and
it's the others that are not allowed)

4. general: always use the terminology "referencing specifications" as
opposed to specifications using ws-context (for e.g.)  I have an action
to beef up 1.2 to make it clear that applications can be refernecinf
specs c.f. the shopping cart.


_________________________________________________________________
Martin Chapman                                 
Consulting Member of Technical Staff           
Oracle                                        
P: +353 87 687 6654                           
e: martin.chapman@oracle.com