FW: [ws-caf] Questions on WS-CAF

["Savas Parastatidis" <Savas.Parastatidis@newcastle.ac.uk>]

Here's another message with questions/issues from Andy Maule (the
student who has been doing some very interesting work using WS-Context
for us here in Newcastle).

Please include his email address in any possible replied.

Best regards,
.savas.

> 
> These are new items:
> 1) On page 14 of the specification figure 4 identifies an element
called
> activity-list. What is the activity list? It is not discussed in any
of
> the
> bullet points in the list below the diagram. The simplest answer is
that
> it is
> simply miss-named and should be called participating-services, which
is
> identified in the bulleted list but not in the schema.
> 
> 2) On page 14 participating-services is not in the schema, but is
listed
> in
> the bullet points. This is a new issue but is associated with
>
http://www.choreology.com/external/ws-ctx.prf_comments.revised.htm#PRF-2
5
> 
> 3) On page 32 getActivityName is defined. How is an activity
associated
> with a
> name? How is it altered or setup? Should it be included in the context
> data?
> 
> 4) On page 16 the SetContext operation is defined which is used to
update
> context information. It does this by replacing the old context data in
its
> entirity, with the context data supplied.  What if the new context
> information
> contains a different URI, should this return an UnknownContextFault or
> similar? What if the new Context information contains child contexts?
> Should
> these child contexts be updated as well? Could this cause problems
with
> maintaining coherence of child contexts?
> 
>   Perhaps it would be better to have operations such as
> setActivityService,
> setType, addChildContext, removeChildContext etc. This would help the
> problems
> discussed above. However addAny and getExtra operation would be
required
> to
> augment the context, using add and get rather than set and get may
help
> prevent intereference and would allow the issue about ALS order of
events
> (item 6) to be solved more easily.
> 
> 5) On page 33 if the new bug caf-116 is correct then getContext takes
a
> context identifier and returns the corresponding context identifier...
> what is
> the point in this?
> 
> 6) If an ALS is used to augment the context information using the
> setContents
> and getContents operations, doesn't this allow interleaving and
possible
> interference or is this handled by a higher level protocol? If this is
not
> done by a higher level protocol perphaps the solution proposed in item
4)
> should be considered.
> 
> 7) If a consumer calls the begin operation, shouldn't this operation
block
> (i.e. not send the reply message) until each ALS has had a chance to
> Augment
> the context as appropriate? Again, perphaps this is handled by a
higher
> level
> protocol, but if not couldn't a consumer start using the context
without
> seeing important context information added by the ALS?
> 
> 8) Should calling getContents (page 16) return the full form of all
child
> contexts recursively, or just in URI form?
>