OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ws-caf message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

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,

> These are new items:
> 1) On page 14 of the specification figure 4 identifies an element
> activity-list. What is the activity list? It is not discussed in any
> the
> bullet points in the list below the diagram. The simplest answer is
> it is
> simply miss-named and should be called participating-services, which
> identified in the bulleted list but not in the schema.
> 2) On page 14 participating-services is not in the schema, but is
> in
> the bullet points. This is a new issue but is associated with
> 3) On page 32 getActivityName is defined. How is an activity
> 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
> context information. It does this by replacing the old context data in
> 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
> 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
> to
> augment the context, using add and get rather than set and get may
> prevent intereference and would allow the issue about ALS order of
> (item 6) to be solved more easily.
> 5) On page 33 if the new bug caf-116 is correct then getContext takes
> 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
> interference or is this handled by a higher level protocol? If this is
> done by a higher level protocol perphaps the solution proposed in item
> should be considered.
> 7) If a consumer calls the begin operation, shouldn't this operation
> (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
> level
> protocol, but if not couldn't a consumer start using the context
> seeing important context information added by the ALS?
> 8) Should calling getContents (page 16) return the full form of all
> contexts recursively, or just in URI form?

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]