[wsia] F2F Meeting Minutes

OASIS WSRP TC Meeting
Boeblingen, September 10th ñ 12th, 2002

September 10
Opening remarks
by Thomas Schaeck

Meeting objectives:

Close on technical issues in the areas of markup fragments, interfaces & protocol, and publish/find/bind.

Agenda

Tuesday September, 10th

09:00 - 09:15 Welcome and Agenda (Thomas)
09:15 ñ 09:30 Brief Summary of WSIA Meeting (Charlie)
09:30 - 10:30 WSRP implementation experiences on Tomcat / J2EE and

        pluggable services (Richard)
10:30 - 10:45       Break
10:45 - 01:00      WSRP Markup Fragments ñ Slot1 (Chris)

Presentation of open and closed activities

        Remaining items to be decided today
01:00 - 02:00       Lunch
02:00 - 03:30      WSRP Markup Fragments ñ Slot 2 (Rich, Alan, Carsten)

        Review of Markup Section of the specification
03:30 - 03:45      Break
03:45 - 05:00      WSRP Security, Identity, SSO (Mark, Rich, Alan, Carsten)

Starting with presentation of open and closed activities,

then go into spec review Ö

Wednesday September, 11th

09:00 - 10:30 WSRP Interfaces & Protocols ñ Slot1 *) (Mike, Rich, Alan, Carsten)

Starting with presentation of open and closed activities

        then go into spec review Ö
10:30 - 10:45 Break
10:45 - 01:00   WSRP Interfaces & Protocols ñ Slot2 **) (Mike, Rich, Alan, Carsten)

Ö spec review continued Ö
01:00 - 02:00 Lunch
02:00 - 03:30 WSRP Interfaces & Protocols ñ Slot3 ***) (Mike, Rich, Alan, Carsten)

Ö spec review continued Ö
03:30 - 03:45 Break
03:45 - 05:00 WSRP Interfaces & Protocols ñ Slot4 ****) (Mike, Rich, Alan, Carsten)

        Ö spec review continued
07:00    Dinner ñ Authentic Swabian Food in the Burggrill at the Pfefferburg

Thursday September 12th
09:00 - 10:45 Simple Properties and Entity Management Discussion
10:45 ñ 11:00 Break
11:00 - 11:30      JSR 168 Overview (Stefan)
11:30 - 12:30 Remaining Issues
12:30 - 01:30   Lunch
01:30 - 03:30      Remaining Issues
03:30 - 03:45   Break
03:45 ñ 04:30      Merging the commitees ?

Milestone Update, Further steps (next meetings, spec milestones)

        adjourn
04:30 - 05:00    WSRP Publish, Find, Bind & Metadata (Richard)

Roll Call for WSRP Face to Face Meeting

Yossi Tamari, SAP Portals

Andre Kramer, Citrix Systemshere
Eric van Lydegraf, Kinzan
Michael Freedman, Oracle
Gil Tayar, WebCollage
Yossi Eilaty, WebCollage

Alan Kropp, Epicentric

Sasha Aickin, Plumtree

Chris Brown, Novell

Nigel Ratcliffe, Factiva

Bruce Lucas, IBM

Ravi Konuru, IBM

Madoka Mitsuoka, Fujitsu

Alejandro Abdelnur, SUN
William Cox, BEA
Rich Thompson, IBM

Charles Wiecha, IBM

Richard Cieply, IBM

Carsten Leue, IBM

Thomas Sch”ck, IBM

Review Day 1 WSIA (Charlie)
Alan to walk through requirements to defer or rework.
Document vs. RPC style WSDL.
Object model discussions, session context object.
Property and data model issues.
Markup (Chris)
Centered on URL rewriting concepts since the last F2F. Support Producer and Consumer-rewriting.
Consumer rewriting
Well-known token wsia:QXqKYZJVUWj7G
Carsten: Supports efficient Consumer markup parsing. Optimal string searching using Boyer-Moore algorithm to find token, token needs to be unlikely to occur ìnaturallyî in the markup stream and long enough, hence the token above.
Sasha: No escaping method, so not possible to put this token into a document. Also, the token lacks meaning. May be optimal, but that level of optimization is overkill?
Gil: Very good technical solution, but it isnít ìsocialî? Logically correct, but abstruse. Problem when it goes to the public, and it will be difficult to remember.
Yossi: Can the token be non-const, in the meta-data? Rich, et al: Problem with parsing static content, donít want a dynamic token in that case.
Gil: Wouldnít Producer-URL rewriting be preferable for some implementers? Why force Consumer-URL rewriting? Carsten, et al: Lots of templates to be transferred.

Thomas: Alternative token? Gil: Compromise on an easily-remembered acronym.
Adrian: Producer-side, no token needed. Consumer-side static content, go with a human-readable token.
Proposal: Vote for Human Readable token: 11 For, adopted.
Chris: Need to choose a token, sub-committee?
Thomas: Take decision tomorrow on ërewriteí as the token, prefix tbd based on further discussion (joint spec name if different?)
URL types
Producer rewriting
10 templates presently. Rich: secureURL Boolean doubles this number.
Gil, Rich: alternate proposal: 2 templates (secure/non-secure)Ö.keep the urlType as the Producer specified (not encoded in the URL), and the Consumer on link activation introspects on the urlType and handles accordingly.
Carsten: This puts more of a burden on the Consumer.
Gil: Maybe another template to supply a default in the event a different base URI is needed (e.g., request vs. resource URLs).
Proposal: 2 Default templates (secure/non-secure), replaceable property urlTYPE in the default, to be used for any of the standard templates that arenít sent. Vote: 10 For 2 Opposed, adopted.
Gil: URL rewriting semantics indicate that if a Producer supports Producer-rewriting, it must also support Consumer-rewriting.
Sasha: Rewriting style for an entity is an all-or-nothing proposition. Canít mix styles.
Adrian: Why are Consumer/Producer-rewriting intertwined in a way that makes it difficult to pull one of them out?
Thomas: It is critical that we donít mandate excessive complexity on the Producer.
Gil: Have a Boolean in the markup response that explicitly indicates if the Producer did rewriting or not. Informs Consumer to (not) do rewriting for a given URL (e.g., resource URL). Consensus in favor.
Carsten: Global global defaults at the spec level. Facilitating mixed rewriting. Consensus in favor.
Producer metadata indicates what rewriting Producer wants to do, and Consumer must comply. Consensus in favor.
Resources
1. Fully qualified URL
2. Portlet Offered? (via SOAP). Is this needed? Gil: s/b stateful. Alejandro: must respect transport-level requirements (i.e., cookies)? Rich, et al: Not the right point yet for this discussion. Need to carry the session ID in the call (JSessionID in the URLÖbut that wouldnít work for .ASP). Consensus in favor of deferral.
3. Consumer Proxied. HTTP GET for resource by Consumer.
4. Well-known resources. Common icons, etc. Gil: Is this pushing customization through the back door? Slippery slope, this set could expand. Sasha: nice to have, but not mandatory for 1.0. Alejandro: Localization also an issue. Consensus in favor of deferral.
Charsets
UTF-8 recommended. Gil: How does Consumer know if UTF-8 wasnít used? Thomas: Need indicator if it wasnít. Sasha: This is complex. Vote: Make UTF-8 mandatory for URLs: 15 For, adopted.
Carsten: What if templates sent by Consumer donít match Producer charset? Gil: Producer must deal with that, or use Consumer rewriting.
Gil: Either Producer responds in Consumerís charset, or in base64? Sasha: There are URL-unsafe chars in base64.
Rich: UTF-8 recommended by W3C for url encoding, this may not match the markup encoding. Same recommendation for markup.
Gil: Producer should always fall-back to UTF-8, in the event it doesnít support the Consumerís desired encoding? Consensus in favor.
Markup rules
Xforms:model? Voice XML? CHTML? Consensus in favor of deferral.
CSS Style
Use same prefix as for other base WSRP names.
Portlet Decoration
Modification of a Portlet title? JSR168 supports through prepare(). Carsten: Leave it out, itís eventing. Rich: Consumer could construct the decoration at any point, so could late-bind the decoration after markup received. Alejandro: This is an adminís choice, they can manually specify a title. Adrian: The Producer shouldnít be allowed to hardwire the title of the portlet. Itís more of a suggestion, which the Consumer is free to take or leave.
Thomas: Static titles for 1.0?
Alejandro: JSR168 exposes this capability, so we donít want WSRP to block it.

Thomas: Encode portlet title in the markup, Consumer should find it there and set it. Alejandro: Extensibility? Include images, etc.
Encode it as a field of the markup response. Vote: 11 For, 1 Opposed, adopted.
Yossi: Should all portlet-defined modes be exposed by the Consumer? Rich: What if the Consumer doesnít comprehend the mode? Still ok to expose it.
Sasha: ëSummaryí mode?
Sasha: Problem with the way mode is handled now. Mixing two metaphors in present spec, as mode is a member of every request. Why wouldnít this just be encoded as navState? Shouldnít ëmodeí be the ëentry pointí for the Consumer to activate a particular feature, and hence a part of navState? The display aspect (Help, etc.) of mode could be handled by the Producer in the response context.
Carsten: If mode activation is buried in navState, how can the Consumer do mode-based access control?
Rich: getMarkup() is too late for the Consumer to effect presentation based on mode. So it could be returned by performInteraction() instead.
Adrian: Do different navStates for all of the modes end up layered together?
Yossi: This wouldnít apply to EDIT mode. HELP mode is a different story.
Rich: Does the Producer manage mode transition on exit from HELP mode, or is it the Consumer?
Gil: Consumer uses performInteraction to switch modes (changes navState). Producer responds by encoding new navState (with new mode) back to Consumer, along with original context state for return. Producer forces mode changes by encoding performInteraction (mode change) URL in the markup. Rich: This canít be mandatory, since the remote Consumer must be capable of denying the state change if the user doesnít have access to the new mode.
Alejandro: In JSR, mode change only allowed in action(). Gil: parallels prior comments.
Rich: Consumer can switch a mode based on clicking a decoration control (itís own URL, not a Producer URL). This could be a getMarkup rather than performInteraction. This is a problem, since entity canít change navState on a getMarkup.
Does this represent a state change for the portlet? Or is it a different view of the entity that the Consumer is specifying? Carsten, Thomas: Consumer, current mode always specified in request. This is the current spec. Gil, Alejandro: Consumer can ask for a mode switch, Producer can encode a mode switch (Consumer must (SHOULD?) honor).
Adrian: We should stick to solving this issue for WSRP, and not attempt to align it to JSR168, which is itself in flux.
Alejandro: For this version, Consumer manages the mode, Producer not able to specify mode switches (later version will revisit)? Andre: But this wonít work, since Producer would need to specify a mode switch back to VIEW from EDIT, for example. Alejandro: Agreed, withdrawn.
Bill Cox: Concerned that this discussion isnít sufficiently backed up by consensus on role semantics. Are we inventing a mechanism to solve a problem that isnít well understood?
Vote: Gilís proposal: 2 For, Carstenís proposal: 2 For, Inconclusive, spec remains as is.
Misc
Rich: Change Window State to View State? Others: confusion
Rich: If we defer Properties in v1.0, how do Consumers send template settings to the Producer for Producer-URL rewriting?
Yossi: Disallowed tags need to be truly disallowed, or just not recommended? FRAME and FRAMESET truly should be disallowed, but other tags could be handled properly by a savvy Consumer. Thomas: WSRP must emit valid fragments that can be readily aggregated. Adrian: This is more a discussion on supporting additional content types (Gil: markup types?). Either returning a whole HTML page (document), or just an HTML fragment (out of a restricted set of HTML), etc.
Vote: to support consumption of entire documents as well as fragments in v1.0: 6 For, 7 Opposed, defeated.
Yossi: CSS menu styles seem limited, should we even try? Rich: reference implementation should fully exercise this and other styles.
Security (Mark)
Secure Transport
wsia:secureURL in markup signals Consumer to use secure transport.
Sasha: can URLs only be http/https? Mark: Yes.

Can a session be preserved across http/https bindings, if the protocol binding changes during the lifetime of the session? Still an unknown.
Rich: Since bindings are at a Producer level, there is entity meta-data that specifies if secure communications required. needsSecureClientCommunications = {Never, Sometimes, Always}.
Gil: Combine Never and Always? Rich: Producer may host entities with different security levels, so canít assume all secure or non-secure Producer-wide.
Rich: rename to needsSecureCommunications?
Thomas: If mixed security factor doesnít work out, we fall-back to Always (for the case the entity does require at least some transport security), Never otherwise.
Roles
Abstract access levels: Admin, Page Designer, User, Viewer.
Gil: The portal controls all calls to the Producer, so why do we need abstract WSRP roles expressed in the protocol? This is different from portlet-specific roles that can be used to control access to portlet functionality. In which case it could be sent in getMarkup() and performInteraction().
Mark: Agreed.
Gil: These abstract roles could be suggestions for portlet-specific roles.
Mark: What about roles on setProperty()? Gil, et al: Yes, if the properties factor remains in v1.0.
Bill Cox: Distinction between roles for managing the portal itself vs. roles intended for managing the provider (i.e. portlet). Itís the latter that WSRP needs to be concerned with.
Charlie: Portal could manage roles entirely internally?
Proposal: Donít pass roles, except in interaction (property) operations.
Sasha: Producer defines its roles in EntityType metadata? Not necessarily the four abstract roles? Rich: Yes.
Alejandro: Do we need descriptions for pre-defined roles in the protocol? Rich: Yes, to allow Producers to more concretely define the semantics of a role in terms of its service.
Sasha: Are role names globally unique? Gil, Rich: Producer-scoped.
Possible conflict with SOAP 1.2 role concept? SOAP roles not used in the same way yet could still cause confusion.
Federated identity vs. Delegated identity.
User Profile attributes
Adopt P3P standard user attributes. Hierarchical schema, so discussion in SJC has been to have a flat array of attribute strings.
Sasha: If we decide to drop consumer registration, there wouldnít be the ìhookî to specify support for named extensions at registration time. Rich: Not so much that registration will be dropped, but that it might become an out-of-band process.
Thomas asks Alejandro about JSR user profile support. Alejandro: voted down at face-to-face. Issue resurfaced in subsequent concalls.
Sasha: X.500 properties, explicitly? Rich: Are there X.500 properties that arenít covered in P3P?
Mark: Lots of overlap between X.500, P3P, etc., at least at a conceptual level.
Rich: Portlet must be prepared for two possibilities if it requests user profile: 1.) The portal doesnít have it, or 2.) The portal wonít release it (provided it does have it) due to policy considerations.
User Identity
Not addressed by WSRP in any context objects/signatures.
Various proposals: WS-Security (preferred, but still evolving), SAML (complex, not widely adopted yet), or define it as part of the UserContext (eventually throw-away).
Gil: WS-Security is securing transmission between endpoints, but not necessarily useful for passing user identity? It would be a stretch to use it that way.
Mark: SAML may support a WS-Security binding that defines how identity could be carried in a header.
Gil: Arenít SAML and WS-Security being combined in OASIS Security TC? Rich, Bill C.: No. OASIS is trying to construct a roadmap for interoperability between security-related specs.
Gil, Sasha, Rich: Do we really need to send user identity to the portlet? Put the unique profile key in the UserContext, principal, etc. in the UserContext for now, and then later it would be discarded in favor of a standards-based approach.
Gil: This must be a trusted ID. Encrypted, transmitted securely.
Chris: Isnít SAML the ultimate solution to user identity problems? If so, letís defer this discussion.

User authenticaton
Auth level enforced by Consumer. Mark: Should defer for SAML.
Eric: Defer, and out-of-band for Producer/Consumer who may wish to establish this trust level.
Other topics
Thomas: Roles required at all (Charlieís point earlier)? Gil: The use case is portal role-mapping to portlet roles. The four abstract roles are themselves pretty useless, in terms of plug-n-play.
Gil: Better abstract roles might be User, SuperUser (Andre: Guest). Mapping will be clearer, but that doesnít preclude portlet supporting custom roles, and/or not supporting the abstract ones at all.
Proposal: Producer can expose 3 pre-defined roles (e.g., Guest, User, Admin). Simplifies Consumer mapping, although Consumer is not required to map these. Consensus in favor.

September 11
Interfaces/Protocol discussion today.
Issues list has been updated to incorporate latest comments from Sasha, Mike F., etc.
Review high-priority items. (Number of votes) indicates relative priorities.
Properties in 1.0? (11)
Charlie to run through discussion from Monday. Persistent (entity): customization of entities. Yossi/SAP: includes end-user property setting? Charlie: Yes, programmatically. Transient (session): Produce-side URL rewriting properties (templates), session setup (customization at start of lifecycle), ìpunchoutî, ìincrementalî during user interaction (not just at lifecycle start).
Gil: another u/c use properties as a vendor extensibility mechanism, i.e., username/password for SSO.
Thomas: Also want to consider how this might relate to eventing mechanism
Proposal: Defer Properties to a later version? .
Current interface status: Property descriptions, get/setProperties, piggy-back on performInteraction/getMarkup.
Yossi: Weíre trying to do too much. Charlie: TC discussions havenít focused on Property mechanism to date. Yossi: Alejandro: We had the original concept of simple string name-values. In JSR we have simple preferences, typing, description.
Alejandro: EDIT mode is for user. API would permit Consumer to customize entities. Without it, would force all customization through the EDIT mode to the entity, even clients for which that would be hard.
Thomas: 1. No properties 2. simple properties, get/set API 3. flexible property mechanism (unlikely to get in 1.0).
Gil: A 4th, session-based property-based. 2 u/cís: 1. session setup (no entity per user) 2. Entity-scoped extensions.
Alejandro: Persistent config vs. transient attributes? Gil: bg color property. If thereís only entity level scope, then an entity required per user. Alejandro: JSR168 supports 2 level preferences, user and entity.
Andre: Do we expect pnp if Producer/consumer need to agree on session-based properties?
Bill: Can we get a sense of the groupís general preference, before delving into details?
Sasha: Donít want any Property consideration in 1.0?
Charlie: If thereís a middle ground approach.
Alan: Think we want at least session-level persistence. Yossi: Agree, this doesnít necessarily introduce incrementally greater difficulty?
Thomas: Dividing line in terms of difficulty could be session-level.
Mike: We havenít discussed yet who manages persistence, so is this level of discussion premature? Consumer-managed vs. Producer-managed. Thomas: Last F2F we concluded Producer manages entity persistence, but if it canít then the Consumer would need to. Mike: But this means the Property mechanism needs to support both.
Rich: With just EDIT mode/opaque state, but thereís no way to invoke it in markup.
Thomas: Do EDIT mode via performInteraction. Rich: Think we need a separate interface. Mike: Yes, but this needs to be a higher-level discussion. Still need to determine entity management issues first.
Thomas: Opaque state management must work, and it can be configured via EDIT mode. Consumer persists in this case? Mike: But it doesnít seem natural for the Producer to provide a UI, but no persistence. Why is this a requirement? Rich: Nature of state being returned isnít necessarily a blob, but it could be a transparent name-value list.

Sasha: Donít see a clear use case for transparent Consumer-side properties. Itís not an important enough point to consider.
Step thru scenario of a Producer entity being configured thru cloneEntity/EDIT mode.
Consensus on whether to defer from v1.0:
Producer-stored entity state (14 yea/3 nay)
Consumer-stored entity state (14 yea/1 nay)
Consumer provided Edit UI (7 yea/8 nay)
Vote: Defer support for Consumer-provided UI from 1.0? 6 For, 11 Against, Defeated.
Alejandro: Gives JSR status on simple preference. This is a vote on support for transparent properties.
Gil: Since not deferred, this implies support for Consumer and Producer-stored state.
Producer provided Edit UI (16 yea/0 nay)
Hierarchy?
Gil: Consumer-hierarchy requires transparent properties. Producer-hierarchy semantics must be fully defined. Too difficult in 1.0 timeframe.
Thomas demonstrates how Producer hierarchy could be supported.
Thomas: There will be only entity properties. There are no transient properties.
Consensus: Hierarchy will not be explicitly supported in the 1.0 spec.
TBD: Resolve property description (tomorrow)
Interface factoring? (11)
Mike: Main issuesÖ1. Technical issue related to the need for supporting shared sessions, where shared session represents an http cookie. 2. Usability: slice or layer the API to provide simpler vs. more complex models. 3. How does a Consumer discover what factors exist, and which to use?
Carsten: Thereís another technical issue: to factor along secure/non-secure dimension.
Rich: Letís start by resolving one of the open issues: WSDL does/does not permit ports to communicate with each other? Whatís really being said; the output message of one port cannot be the input message of another port in the same service. So itís a non-issue.
Carsten: Cookie/load balancing. SOAP doesnít explicitly support transport-level load balancing through cookies, although common implementations actually do support cookies. Do we need a separate factor for cookie-handling?
Gil: So, instead why donít we have a single WSDL interface, and Boolean settings to indicate what features Producer supports? Rich: Factoring is at a port level; so that forces the single interface to be, for example, http or https.
Sasha: Web services arenít sufficiently mature yet, so we find weíre having to invent scaffolding in those places that WSDL, SOAP, etc. arenít addressing. Charlie: We need to be careful not to bite off too much, though, because these are in fact being addressed.
Andre: Need to support a WSRP-specified approach for load balancing. WS-I will say, however, that support for cookies is required, so this should influence specs like WSRP.
Mike: Should certainly support both cookies and Producer-supplied load-balancing mechanism.
Rich: initEnvironment() to initialize the shared session, but if Consumer invokes both secure/non-secure requests, how can the cookie/shared session cross the different bindings.
Gil: There is no connection between establishing a shared session scope using initEnvironment, and using it for initiating the load-balanced shared session.
Consensus: Canít share sessions across bindings (http/https), and that we support additional factors for cookie support.
Consensus: Consumer strongly encouraged to respect transport-level synchronization mechanisms (cookies)
Mike: 3 layers to the interface presently, starting from bottom-up: markup generation, entity management, and consumer identification.
Rich: Two factors presently: getMarkup-performInteraction-initEnvironment, and registerConsumer-modifyConsumer-cloneEntity-modifyEntity-releaseHandles-getDescription-Properties. How should this be changed? Factor the Consumer operations into a third factor (add deregisterConsumer).
Mike: Fourth factor to discover the factors supported (getServiceDescription). Always the same (Gil: forward compatible) for all new versions, making this the one ìsafeî factor.
Gil: getServiceDescription should not return WSDL. WSIL will define this instead.
Rich: Could remove getServiceDescription; just put meta-data in the WSDL. Mike: This forces environments that represent meta-data differently (i.e., JSR 168to ìback-generateî the meta-data into theWSDL. Consensus: This would be bad. Meta-data should not be in the WSDL.

Gil: Seems bad to use WSDL as the factoring description mechanism. Mike: This is necessary since factors can have alternate bindings, and that is WSDL information.
Mike: getServiceDescription should be version-safe, so it needs a simple signature. Remove WSDL field from the return value.
Gil: How can I make initEnvironment optional? Can it be a separate factor? Rich: Could be really ugly. To indicate initEnvironment is optional in the base factor is meta-data (Boolean).
Mike: For WSRP, all 4 factors should be required (though minimal implementations of some of them are ok)?
Vote on 4 factors: 1. 20/0 2. 9/5 3. 0/15 4. 1/1
Extensibility (4)
getEntityDescription re-factor (0)
Covered above.
EntityState necessary? (1)
Cookies, load balancing?
Entity management?
Entities/Window state (2)
registerConsumer in 1.0? (3)
performInteraction/getMarkup in one step?
Thomas: Optionally return markup from performInteraction?
Sasha: Not in agreement, optimization could take place later. Also, signatures are already complicated.
Rich: Could do it later after we have more experience with the spec.
Vote: Do this optimization now: 5 For, 8 Opposed, defeated.
Object model discussion, merge entity/session handles? (6)
Tomorrow
Caching in 1.0? (1)
Yossi: Portals will do their own caching regardless of whether WSRP supports it.
Thomas: A simple WSRP mechanism is required in v1.0. Expiry provided on the response, keyed by all parameters in the request (less excluded parameters).
Alejandro, Mike: JSR discussions on this point conclude that ìsimpleî isnít really feasible in the v1.0 timeframe. Make it a per-vendor extension.

How does Clone and Config work? (2)
InitEnvironment (6)
Signatures (3)
Gil: There should be less obscurity, more 1st level parameters.
Rich: Signature cleanup should wait pending higher-priority resolutions.

September 12
Property discussion today (Charlie). Proposal for lightweight XForms.
Issues list has been updated to incorporate latest comments from Sasha, Mike F., etc.
Review high-priority items. (Number of votes) indicates relative priorities.
Property Description Strawman
GetEntityProperties(consumerContext, entityContextÖ)
SetEntityProperties(). ChangedProperties structure returns.
V1.0 supports a single model. V2.0 evolves to support multiple models.
Bruce: can properties change as a result of a performInteraction? Perhaps this structure should be returned as a result of other operations.
Alan: Agree.
Rich:
Alejandro: JSR concept of layered properties permits removal of properties, so that the higher level value takes effect. Also, JSR doesnít limit property set to just that published in the entity metadata. It would be nice to have this in WSRP.
Charlie, Rich, et al: Firm decision already taken not to support runtime properties, at least not outside of an extension mechanism.
Gil: If Producer doesnít support persistence, Consumer canít setEntityProperties on the POE. Charlie: Need to pass a context, so the implication is youíd need to clone. Mike: If you only have POEís, you have const portlets. No customization. Rich: And no Consumer-stored state.
For a portlet to be customizable, it has to offered Producer-stored state: Rich, Carsten, et al: No. Mike: cloneEntity returns a new entity context, and the state can be stored opaquely. Even the handle doesnít get persisted. The main point is that cloneEntity creates the context, and the question of persistence is orthogonal. It can work either way, although in the non-persisting case itís something of a no op.
Charlie: This is off-topic.
Sasha: v1 supports name-values in the property list. V2 evolves to support expressions (Xpath) in the name. Is setEntityProperties atomic? Charlie: good topic for email.
Mike: Why are we carrying what amount to simple name-values in this format?
Gil: Is this format not convenient for standard SOAP stacks? Bruce, Sasha: Off-line analysis could help format so it interops well with the stacks.
Alejandro: JSR supports multi-values, valid values, etc. Rich: schema will permit us to support that and more.

Mike: Is this description sufficient to do good UIís? Bruce: Probably not, but enough people feel like a basic solution needs to be in 1.0.
Mike: Consumer is not bound to render a UI based on this description? Rich: No, but if thereís no entity Edit mode, thereís essentially no configurability. Mike: This will probably force all Producers to implement an Edit UI. Alejandro: It is not advisable to for the Producer to depend on the Consumer to do a UI anyway.
Vote: 16 For, adopted
Entity management?
At what point is an entity created in Edit mode? At the end of the configuration?
Chicken and egg issue, at what point does entity instantiation occur? Before/during/after the configuration. Rich: this may depend partly on whether thereís Consumer-stored state. Also, what happens if the Edit mode is aborted?
Sasha: Even for Producer-stored state, itís a problem. What if users using the same entity want to modify the state? Rich: This requires a configured entity per user.
Carsten: The implication is that changed property state should be returned in performInteraction (getMarkup?).
Thomas: To support copy on write, Consumer would need to flag Producer when one of its users is changing entity stateÖProducer would then need to clone at that point.
Yossi: If a portlet supports Edit mode, assumption is that entity always changes its state.
Gil: Rather than pursue a complicated ìcopy on writeî scheme for the entity creation, does the simple thing: clone immediately on entry to Edit mode. Destroy if thereís a problem.
Alejandro: Concern from JSR is that property change can take place outside of Edit mode.
Gil: The Consumer should be in control of entity clone creation.
Andre: Could still support copy on write through the use of a Boolean mustClone?
Adrian: Sounds like weíre mixing concepts. Mixing user state into entity state at this stage is causing confusion. Rich: In fact, itís ìuser entityî state, or entity state keyed off a user. Different from user state.
Rich: Add a flag to interactionContext that entity state changes are safe. This way, the Consumer doesnít need potentially two round trips for performInteraction with a portlet that may change state.
Alejandro: Seems like it would be a better v1.0 solution to support Andreís proposal. Adrian: And if it turns out to be a problem, we can always revisit it with the more optimized proposal.
performInteraction(stateChangeOK?)
If true && State change detected, Producer responds with notification to Consumer that it needs to change state. Consumer decides whether to clone, and then resubmits the performInteraction.
performInteraction(mustClone?)
Bit in entity meta-data to Consumer that it should clone. Rich: This is inefficient, because it forces per-user cloning. Mike: This also breaks the ability to have a shared set of customizations for all users. If itís clone-on-view, then we lose the ability to have state modification on the default portlet and make it visible to non-customizing users (unless there was Producer hierarchy, which we decided not to support), all of whom have their own clones.
Vote: 12 in favor of exploring the complex solution
JSR 168 Presentation (Stefan)
JSR is still discussing whether there will be a Group scope.
Bruce: No formal relationship between Preferences and entity scope? Stefan, et al: Yes.
Sasha: Is there per user/per entity state? Mike: This is somewhat related to the prior discussion about cloning in response to entity state. Answer
Gil: What is the user? Adrian: J2EE Principal.
Eric: What is the window scope? Mike: Instance in the portalÖmultiple instances could share the same entity.
Alan: Portal custom modes? Stefan: Must map portal custom modes to those modes the portlet described in the metadata.
Object model discussion, merge entity/session handles? (6)
Rich: Object model discussion led to conception that the session could be viewed as a refinement of the entity at runtime. What should the impact be on signatures?
Rich: Current signature pros and cons. Main ëconí is that the signatures must carry 3 different handles, and the Consumer must persist and use them correctly.

Rich: Change proposed. 1st class refHandle the same as the entityHandle until a sessionID is returned, upon which the refHandle is the sessionID. Simplify signatures by removing redundant handles. Producer must do the encoding to unify the two handles, but that means the Consumer doesnít have to do it (and potentially do it wrong).
Andre: What happens if the session times out? How do we re-establish the session on the entity? Rich: The handle carries both the entity handle, and the now-expired session handle.
Alejandro: Framework could be creating the handle, and doesnít permit any changes to it. Rich: Itís not changing the underlying layerís handle, itís encoding it in a higher-level representation.
Sasha: Doesnít this obscure what entities a Consumer is interacting with? Rich: Entity handle is still there; Producer may refine that handle to include a session. Sasha: This doesnít seem like itís really following the spec. Gil: Itís a simplification.
Alejandro: Why not encode the user ID as well? Sasha: The Consumer ID? Bruce: We should start down this road, and can add further refinements.
Carsten: The problem with encoding Consumer ID would be if the entity were published in a UDDI registry, would the registry need to include entries for all entity/Consumer combinations? Mike: Do we guarantee that all new refHandles are always transient? Rich: Yes.
Alejandro: Is it one of the main goals to avoid the problem of attempting to call an entity with the wrong sessionID? Charlie: Itís a consequence. Alejandro: What are we gaining by doing this? Rich: Itís cleaner model, reflects the tight binding between an entity and its session(s).
Vote: 6 for, many abstentions, adopted
Signature Efficiency/Beauty/Form
Rich: Really hard to discuss in light of all of the decisions taken during the meeting, needs to happen after a new version of the spec is available for review.
Gil: Post the relevant issue and details to the mailing list, and heíll add it to the issue list for tracking. Heíll email the list with the process.
registerConsumer out of band?
Gil: Donít think we can get a well-designed version of this into 1.0. Vendors probably have their own requirements. Keep the interface, define the context objects as <any/> XML content.
Yossi: We should keep the present interface, with the basic fields as they are. Vendors (and others) can add to it over time.
Rich: If itís not possible to keep it in band as it is, then it should be removed from 1.0.
Mike: Think we need to get this in 1.0, and make it robust. For example, this is how the Producer/Consumer negotiate optional capabilities.
Vote: Remove registerConsumer from 1.0? 3 For 8 Opposed, defeated
Extensibility
Gil: 1. Add operations 2. Extending operation signatures 3. Extending context objects.
Rich: WSDL 1.1 operation names can be overloaded, but this was removed in 1.2. So itís not possible to extend operation signatures and keep it within the same service.
Bruce: Whatís wrong with saying all extensions are handled in different portTypes? Gil: Thatís to handle adding new operations. Sasha: This is essentially saying that all extensions are handled outside of the spec.
Gil: Refine the question: how can we extend a signature while remaining within the confines of the spec? Rich: One of the telecon discussions about payload extensibility without requiring new portTypes.
Gil: Also the issue of version compatibility. Forward compatilibity is much more difficult to assure if the WSDL gets fractured into extensibility portTypes.
Charlie: Having AVList as a member of all or most of the context objects seems really ugly. Itís a backdoor to extension. Much better to expose extensions explicitly via separate interface(s).
Andre: Itís possible to keep the data extensibility confined to the SOAP level, as a custom header. Also, it may be possible to use the registration as the point to exchange extended data. Carsten: A little messy, but it wonít impact the interfaces. Mike: How does this work? Carsten: Just extract the header using the local SOAP stack. Mike: JAX RPC doesnít support this capability(?)

Thomas: 2 options. 1. Data extensibility (AVList) 2. Interface extensibility (different portTypes).
Sasha: Why not pass everything in the header?
Rich: We havenít mandated support for SOAP. This canít be what the spec says is the extensibility mechanism.
Richard: SOAP headers are supposed to contain message meta-information (routing, etc.). Itís not intended to carry ìpayloadî. Sasha: Donít think itís clear what constitutes ìpayloadî, and it may be perfectly valid to put this information in the header.
Mike: If we represent factor extensions as new portTypes, how does the Consumer detect this? Bruce: The Consumer would need information about the Producerís extension.
Bruce: Why not take the true XML approach with data extension, and define a namespace/schema. Rather than an array. So the base WSDL would have an XML <any/> extensibility element, that binding WSDLís would need to fill out. Rich: To make this useful, there would need to be a registered serializer/deserializer for proxy stub generation.
Mike: Whatís the added value for typing the extensibility elements, instead of the present name-values?
Vote (1st priority 2nd priority): No explicit extension mechanism (SOAP headers, portTypes)? 4 3
Vote: XML <any/> extensibility: 5 7
Vote: AVList: 2 1
Merge Committees
End of year, post 1.0(?). No decision today, just raising the issue for discussion.
Yossi: Worried about the impact on WSRP, it will get too complex.
Gil: We could merge now in recognition of the work done on the joint specÖand then consider whether thatís a good arrangement to continue in the post 1.0 timeframe.
Sasha: Very much in favor. Difficult to describe what the differences are to people. In this F2F even, the WSIA meeting on Day 1 was forced to hold on decision points pending WSRP meeting.
Bill: Make a decision after 1.0. The difference is WSRP is focused on the most concrete, immediate case, WSIA proposes a framework that starts from that point. To decide now will defocus us.
Alan: Agree with Bill. There is value in the two specs evolving as separate entities, obviously with some level of coordination, because both specs address a different (sub)set of the web service world, and hopefully with two efforts we devote the right effort to each.
Charlie: Doesnít see much of a difference in the goals that the committees are trying to address. There is a lot more overlap than differences in the two efforts.
Yossi: Post 1.0, if each committee draws up its own 2.0 goals, we can determine then if thereís sufficient commonality to merge.
Charlie: It would be more efficient and useful for the two groups to work on a unified charter, rather than draw up separate charters and then have to merge them.
Bill: The way the groups have been functioning administratively has been as separate groups, even though theyíve been working in a coordinated fashion.
Gil: De-facto, we are already one committee. So, begin operating as if we were one committee to eliminate some of the administrative overhead, even though there are (still) separate charters. Decide to split at some point in the future.
Bill: Would a merged group be easier to schedule?
Sasha: We should make the F2F fully joint, instead of splitting into a WSRP/WSIA meeting.
Milestones
IBM demoíed an early version of the POC Implementation
Spec editors provide a new (initial public draft) version of the spec on 9/27(!), TC comments through 10/7. Mike: Donít believe that this will really be the base public draft. There are still open discussions. No way we will have a public draft on 10/7.
Bill: There needs to be a date at which we put the specification under strict change control, track issues formally, work through the issues. This schedule is unrealistically tight given what remains to be done to bring the spec to public draft.
Sasha: Agree, think weíre basically behind by one F2F.
Gil: Agree with Sasha. Motion we add another F2F to the schedule, and push out final release date accordingly.

wsia message