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


Help: OASIS Mailing Lists Help | MarkMail Help

wsia message

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

Subject: [wsia] Background for object model discussion during Thursday 8/22WSRP interfaces call

Folks -- I volunteered to work up some details of the "object model"
discussion we started last week, i.e. around unifying our treatment of
entities and sessions as different levels of scoping rather than
fundamentally different concepts...here are some questions and possible
implications for the interfaces that result for discussion tomorrow.

Charlie Wiecha


1. Should we think of entity and session as defining two scopes for state
rather than orthogonal concepts?
2. If so, can we imagine wanting to extend these scopes with additional
ones, e.g. request, page, etc?
3. If so, can we think of an extension mechanism for carrying the "context"
bundles at each scope (entity, session, request, page) in a uniform
4. Invoking getMarkup/performInteraction would then take a context bundle
at a given scope, and perhaps return one at a narrower scope
(entity->session) as determined by the producer.

What goals might a unified context mechanism support?
1. Extensibility of WSRP to new levels of scoping (as in request, page)
2. "de-scoping" of WSRP to simpler models of scope, e.g. session only
3. Interoperability among implementations of WSRP supporting differing
scoping models, with common operation signatures, e.g. mixing producers
supporting entities with those that do not

1. Is there a benefit in allowing for additional or fewer scopes in WSRP
2. From an implementation standpoint, is it any easier to implement a
non-entity supporting Producer than an entity-supporting one?  (still needs
3. If so, is there a further benefit in supporting interoperability between
entity-supporting WSRP implementations and non-entity implementations
supporting sessions only?  Can a consumer be written without being aware of
the scopes a given Producer supports?
4. Given a unified context mechanism, should get/setProperties be supported
at each scope?  Should getProperties implement a search through the scopes
or are they independent?

What might the operations look like with unified context structures?
Current signatures:

markupResponse = getMarkup(consumerContext, entityContext, markupContext);

interactionResponse = performInteraction(consumerContext, entityContext,

Possible unified interface:

markupResponse = getMarkup(consumerContext, producerContext);

producerContext = performInteraction(consumerContext, producerContext,

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

Powered by eList eXpress LLC