[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [wsrp-wsia] Issues agenda for 10/24
#48: We had a metadata field called isCloneable. I asked at the Sept F2F
whether this should be kept. The only comment was that this seemed like a
Producer rather than entity issue and that it was declared through whether
or not the Producer exposed the EntityManagement portType. This caused the
field to be deleted and this proposed resolution is just clearing my
initial reminder to raise the question.
#59: I have heard 2 reasons for this field:
1) Standardized place for entities to declare types for payload
extensions they use (i.e. not used Producer-wide)
2) Entities that are directly accessible via additional portTypes (not
shared across the Producer). While this may not be the normal portal
scenario, others have indicated an interest in making this information
available in a standardized format.
#62: This was capturing the F2F decision to head in the direction of the
proposal currently being refined. I am not averse to leaving it open if the
direction is still in question. Refining the details of the proposal should
be done on a more detailed level rather than dealing with multiple detailed
issues via this general one.
#65: This was a request for a presentation as part of synchronizing with
JSR168. We are opening issues as they occur relative to this synchronizing.
#85: The current language allows for exceptional issues causing the
Consumer to effectively throw away the refHandle. Are you proposing that
the MUST be downgraded to a STRONGLY RECOMMEND (I would object to less than
that)?
Michael Freedman
<Michael.Freedman@ To: wsrp-wsia@lists.oasis-open.org
oracle.com> cc:
Subject: Re: [wsrp-wsia] Issues agenda for 10/24
10/23/2002 03:35
PM
I would like to discuss the following items more thoroughly before marking
them as resolved:
(#48) Should an item state that it is cloneable?
Can you refresh my memory and explain why this answer is No?
(#59) Interface discovery
Though an optional field, I still don't understand why its included
at all. The description says this is the URL for the WSDL
description of this entity. What is this? Is this the producers
WSDL that can describe this entity? If so why isn't this a producer
meta data field?
(#62) Entity Management
Isn't this issue still open? Isn't there a proposal on the table to
add cloneOnWrite?
(#65) JSR Synchronization
This is a general issue asking we synchronize with the JSR semantics.
We should either keep this open of open N issues related to the JSR
to keep track of this.
(#85) sessionID/expires MUST/MAY
I am not sure we have the wording right yet. Can you clarify the
explicit wording we propose to use. I am not happy with what I saw
on a quick look through .8. I.e. The way things are written now it
appears that a consumer will not be in conformance with the spec if
it chooses to discard the refHandle for a reason other than given in
the spec. I think a consumer needs the flexibility to manage its
resources -- i.e. choose to drop a refHandle.
Rich Thompson wrote:
This week's agenda is essentially a continuation of last week, though
there
are a different set of issues moving to resolved unless objections
are
raised.
1. Issues moving from tentative resolution to resolved (for
information
only):
(#12) Splitting getEntityDescription for different handles
- done as per Sept. F2F
(#13) Splitting getEntityDescription into functions with explicit
return
types
- done as per Sept. F2F
(#15) Enabling cloneEntities on producers that do not need
registration
- withdrawn
(#17) Defining whether initEnvironment is supported via metadata
- initEnvironment() is in Markup factor with Producer metadata
declaring need for usage - as per Sept. F2F decision
(#20) Is entityState (a persistent state) necessary for v1?
- Yes. It is required for Consumer-stored entity state
(#22) What is the rationale behind returning successfully released
handles?
- releaseHandles was split into two operations, both which
return
either void or a fault
(#32) Do property operations need to be included in base?
- Yes. The Sept F2F declared that persistent properties for
entity
configuration are to be included in v1.0.
(#48) Should an item state that it is cloneable?
- No entity metadata in v1.0 regarding whether it can be cloned
…
Producer managed area.
(#49) Problem in the the use of multiple description records that
derive
from each other
- getDescription was split into two functions. See Issue #12 and
Issue
#13
(#54) WSRP session to consumer – end user session
- Gil's proposal accepted - Specify “WSRP session between
consumer and
producer maps to end user session of the consumer†– what end user
session
means depends on the consumer.
(#55) Shall we have a registerConsumer operation in the 1.0 spec or
out of
band ?
- While out of band is allowed, in band registration for v1.0
was
decided by the Sept. F2F to be included
(#58) Should only POEs be published, only service or both
- Remove UDDI definitions from spec, focus initial efforts on
the
information model that should be published to a directory for a
Producer.
(#59) Interface discovery
- Sept F2F retained wsdl field. If information was gathered
prior to
calling
getServiceDescription() [ by using out of band mechanisms], it can be
ignored.
(#60) Presentation on WS-Security
- A presentation did in fact occur in the September F2F
(#61) Interface Factoring
- Sept. F2F decided to factor the interface using 4 factors.
V0.7
reflects this factoring
(#62) Entity Management
- Process outlined in v0.7 based on September F2F decisions
(#64) Preference management negotiation
- All permutations were approved at Sept F2F. 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) JSR synchronization - request for presentation
- A presentation was in fact…presented at the September F2F
(#68) Do we need initenvironment ?
- Yes. It is needed.
(#76) Why is the fact that Consumer supports transcoding surfaced in
the
spec?
- characterSetConversion removed from meta-data
(#77) specific semantics of sendPublishedState
- sendPublishedState removed from meta-data
(#83) Is markupType a MIME type?
- markupType MUST be a MIME type
(#85) sessionID/expires MUST/MAY contradiction
- Language updated ... Basically MUST with a couple of
exceptions.
(#87) Modes as navigation state vs. Modes as another state of the
Entity
- It was decided in the September F2F that Mode is a piece of
state
related to the Consumer's viewer, not the entity's state
(#95) destroyEntities() & refHandles
- 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.
(#103) In vendor extensibility "object any" should be an array
- Captured in v0.8 ... actually change for interoperability
reasons
was to "Extension[] extensions where an Extension object just
contains an
<any/>
2. (#92) Maximum size of a handle
- Ongoing discussion, need to arrive at a conclusion ....
3. (#96) Review well known URL parameter names
- Draft v0.7 has (are other needed?):
wsia:navigationalState - sets this for the entity
wsia:mode - requests a mode change before invoking the entity
wsia:windowState - requests a windowState change before invoking
the
entity
wsia:urlType - describes how to process the activation of this
url
wsia:url - the url of a resource for when wsia:urlType=Resource
wsia:token - the token for namespacing when
wsia:urlType=NameSpace
wsia:secureURL - specification that the rewritten url should use
secure
communications
wsia:rewriteResource - flag indicating whether the Consumer must
parse
the indicated url for url rewriting
wsia:clientParameters - Producer url writing place to put
arbitrary
clientParameter list
wsia:refHandle - Producer url writing place to place refHandle
for the
resulting invocation.
4. (#18) Mandating the use of initEnvironment if Producer needs it
- Draft v0.7 has the following in the description of
initEnvironment: "If
the Producer's metadata has set the doInitEnvironment flag to true,
then
the Consumer MUST invoke initEnvironment() once for the groupID prior
to
invoking getMarkup() for this End-User for any entity using the same
groupID."
5. (#42) Why does consumer need to tell producer which extended
attributes
it supports?
- Do we need to add explicit verbiage to the effect that a
producer/entity
may tailor its requested items (e.g. userProfileItems) based on the
information the Consumer supplies at registration time?
6. (#45) Signaling state change in InteractionResponse
- The description of navigationalState tries to capture that a null
return
value means continue using the old value. Is the wording clear? Same
verbiage needed for entityState? How does this interact with
interoperability issues with using nillable?
7. (#51) Define a naming scheme how WSRP binding tModel are named
- Proposal from email list is
"SPEC_VERSION_FACTOR_WSDLTYPE_TYPESPECIFIC"
which would lead to names like "WSRP_v1_Markup_Binding_SOAP".
8. (#93) Payload extensibility mechanism
- The F2F decided to explore using <any/> for this as it is the
natural
mechanism in a schema based system and provides for backward
compatibility
for future versions. On the technical level, has this worked? On the
philosophical level, is it still the way we want to proceed?
9. (#97) Caching mechanism
- Draft v0.7 has timeout and coarse scale keys defined for caching
mechanism. This does not include the ability to invalidate other
markup
from the same Producer. Introducing InvalidationKeys could add this
feature. Do we want to include this in v1.0? Follow-on the discussion
of
ValidationKeys vs InvalidationKeys.
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC