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


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp-wsia message

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

Subject: [wsrp-wsia] Issues agenda for 10/3

Sorry ... I see I failed to change the subject line.

1. (#6') Is groupID required?
 - Proposal is that with the initEnvironment() operation the need for
groupID has been removed and therefore the field should be removed from the

1. (#74) Should the Consumer MAY or MUST releaseHandles?
 - Draft v0.7 makes this change ... is it acceptable?

2. (#75) How to ensure consumerName is unique?
 - Draft v0.7 suggests that the URL of the Consumer could provide such a
unique name. More needed?

3. (#78) Should we specify storage of consumerHandle?
 - Draft v0.7 incorporates the suggested changes. Are they acceptable?

4. (#79) Why return consumerHandle in modifyConsumer's consumerContext?
 - Draft v0.7 introduces a new structure to eliminate this potential source
of error.

5. (#80) cloneEntity() and modification of properties - in same call?
 - Draft v0.7 eliminates this as the F2F decided to not merge properties
into the other operations.

6. (#82) What is the need of previousMode (& previousWindowState)?
 - Draft v0.7 replaces these with a constant for requesting the Consumer
return to the previous mode and a nomative statement that the Consumer MUST
revert to VIEW_MODE ( VIEW_NORMAL in the case of windowState) if it does
not have a previous value to revert to.

7. (#83) Is markupType a MIME type?
 - While the spec is silent on this currently, I think reusing MIME types
makes more sense that developing another set.

8. (#92) Maximum size of a handle
 - Discussion on email list has made the following points:
   1. For portals to operate efficiently, a handle should be usable as a
database key (usually this means 255 bytes or less).
   2. For security reasons, it would be good if the handle is not smaller
than 256 bytes.
   3. Producers may find URLs to be the most straightforward way of
generating a handle ... this drives toward the length being unlimited.

9. (#93) Payload extensibility mechanism
 - Draft v0.7 explores changing this to the schema <any /> mechanism. This
appears to require changing to style="document" and encoding="literal".
Could people explore whether the revised WSDL works with various tools

10. (#94) Is getMarkup() able to modify/return state?
 - Current spec says the semantics are to return markup that reflects the
current state. Propose we ratify that as the semantics.

11. (#95) destroyEntities() & refHandle
 - The F2F introduced destroyEntites(). One question that has arisen is
whether a refHandle can be passed to this operation. Sense of the email
discussion is NO.

12. Open items I have noted as resolved at the F2F. Is there agreement that
these were the resolutions of the issues?
 - (#12) => split getDescription() into 2 operations
 - (#13) => split getDescription() into 2 operations
 - (#22) => split releaseHandles() into 2 operations, both of which return
void or a fault message on failure
 - (#15) => withdrawn by Thomas
 - (#17) => initEnvironment() is in Markup factor with Producer metadata
declaring need for usage
 - (#20) => entityState is required & is returnable by performInteraction()
as well
 - (#32) => simplified property operations for entity configuration should
be proposed
 - (#49) => split getDescription() into 2 operations
 - (#50) => No. Metadata is only defined in messages from get___Description
() operations
 - (#54) => agreement with Gil's suggestion
 - (#55) => in-band operation is defined. Out-of-band process comments
needed in spec.
 - (#56) => simplified property operations for entity configuration should
be proposed
 - (#59) => wsdl field retained. If information was gathered prior to
calling getServiceDescription(), it can be ignored.
 - (#60) => This was a suggestion for a presentation at the F2F
 - (#61) => F2F decided on 4 factors ... reflected in v0.7
 - (#62) => process outlined for Consumer flag & entity fault message.
Review how clear v0.7 lays out the scenario
 - (#64) => All permutations were approved. Persistent state only produced
by entity. In the case of Consumer UI gathering property updates, the
setEntityProperties() sets the entity's state regardless of where it is
 - (#65) => This was a suggestion for a presentation at the F2F
 - (#68) => yes, initEnvironment() is needed.
 - (#76) => Removed this metadata
 - (#77) => Removed sendPublishedState flag
 - (#87) => Mode is a piece of state related to the Consumer's viewer, not
the entity's state

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

Powered by eList eXpress LLC