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: FW: [wsrp-wsia] Tentative resolutions


The issues below have been marked as "Tentative resolve". If I do not hear
any objection from anybody they will be marked as "Resolved" in the
22-Oct-2002.

Gil

-----Original Message-----
From: Rich Thompson [mailto:richt2@us.ibm.com]
Sent: Thu, October 03, 2002 20:46
To: Gil.Tayar@webcollage.com
Subject: [wsrp-wsia] Tentative resolutions






Gil,

Would you put the following out as proposed resolutions?

First from the F2F:
 (#12) => split getDescription() into 2 operations
 (#13) => split getDescription() into 2 operations
 (#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
 (#22) => split releaseHandles() into 2 operations, both of which return
void or a fault message on failure
 (#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
stored.
 (#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

From 10/3 Conference call (Some overlap with editorial list):
 (#74) => Modify v0.7 language to say the Consumer MUST attempt to release
these handles. Network failures should be retried at least 10 times with at
least 1 hour between attempts.
 (#75) => Draft v0.7 eliminates requirement statement, encourages
uniqueness of the consumerName and suggests the Consumer's URL as such a
name.
 (#78) => Draft v0.7 incorporates the suggestion to remove language about
different Consumer implementation choices.
 (#79) => Draft v0.7 introduces a new structure (RegistrationCore) that
eliminates this potential problem.
 (#80) => Draft v0.7 eliminates this piggybacked porperties parameter as
per F2F decision.
 (#82) => Draft v0.7 replaced these fields with semantics of Previous
constants
 (#83) => markupType MUST be a MIME type
 (#95) => Draft v0.7 does not allow refHandles to be passed to
destroyEntities() as the semantics are to destroy the persistent entity,
not a runtime refinement of it.

From 9/26 Conference call:
 (#58) => Remove UDDI definitions from spec, focus initial efforts on the
information model that should be published to a directory for a Producer.

From 9/19 Conference call:
 (#48) => No entity metadata in v1.0 regarding whether it can be cloned ...
Producer managed area.

Thanks, Rich



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


Powered by eList eXpress LLC