Voting Members |
Company |
|
|
Stephen Drye (on leave) |
Art Technology Group |
|
|
William Cox |
BEA |
y |
|
Adrian Fletcher |
BEA |
|
|
Gino Filicetti |
Bowstreet |
y |
|
Steven Smith |
Capitol College |
y |
|
Andre Kramer |
Citrix |
y |
|
Monica Martin |
Drake Certivo |
y |
|
Raj Ramesh |
CommerceOne |
y |
|
Timothy N. Jones |
CrossWeave |
y |
|
Alan Kropp |
Epicentric |
y |
|
Nigel Ratcliffe |
Factiva |
|
|
Madoka Mitsuoka (on leave) |
Fujitsu |
|
|
Sunit
Randhawa |
Fujitsu |
|
|
Richard Cieply |
IBM |
y |
|
Carsten Leue |
IBM |
y |
|
Thomas Schaeck, chair |
IBM |
y |
|
Rich Thompson |
IBM |
y |
|
Charles Wiecha |
IBM |
y |
|
Eric van Lydegraf |
Kinzan |
y |
|
Jon Klein |
Reed-Elsivier |
y |
|
Adam Nolen |
Reed-Elsivier |
y |
|
Petr Palas |
Moravia IT |
|
|
Olin Atkinson |
Novell |
|
|
Chris Braun |
Novell |
y |
|
T.J. Cox |
Novell |
y |
|
Michael Freedman |
Oracle |
y |
|
Mike Hillerman |
Peoplesoft |
|
|
Art Machado |
Peoplesoft |
|
|
Ken Pugsley |
Peoplesoft |
|
|
Sasha Aickin |
Plumtree |
y |
|
Jane Dynin |
Plumtree |
|
|
Joseph Stanko |
Plumtree |
|
|
Michael Young |
Plumtree |
|
|
Amir Blich |
SAP |
|
|
Gennady Shumaker |
SAP |
|
|
Yossi Tamari |
SAP |
y |
|
Rex Brooks |
Starbourne |
y |
|
Brian Dirking |
Stellent |
|
|
Alejandro Abdelnur |
Sun Microsystems |
y |
|
Dave Clegg |
Sybase |
|
|
Joe Rudnicki |
U.S. Navy |
y |
|
Eilon Reshef |
WebCollage |
y |
|
Gil Tayar |
WebCollage |
y |
|
Prospective Members
(non-voting) |
|
|
|
Dan Machak |
Tibco |
|
|
WSIA Members (non-voting) |
|
|
|
Graeme
Riddell |
Bowstreet |
|
|
Bruce
Lucas |
IBM |
y |
|
Ravi
Konuru |
IBM |
|
Dan Gisolfi
|
IBM |
|
|
|
|
|
2 proposals. 1. Schema in 0.7 and 0.8 2. Modified proposal from Yossi that treates items from current draft as scopes and introduces InvalidationKeys.
Gil: Common web app caching mechanism is not expiry, but invalidation based.
Carsten: That’s why the proposals contain cache hints. The “input space” is too large to calculate a key.
Gil: Hinting is a good approach, though there is no certain algorithm that’s going to cover.
Sasha: Actually expiry caching is used extensively. (if not modified eTag). This introduces a “round-trip” for validation.
Mike F: Yossi’s proposal is for invalidation-based caching.
Sasha: Haven’t figured out how invalidation-based scheme intersects with validation/expiry mechanisms.
Mike F: Hierarchy…expiry à hints à state (scope) based à “catch-all” action-based expiry (reset all). The problem with hints/state levels of this hierarchy is that it forces the Consumer to “know” details about the caches.
Sasha: Review Yossi’s proposal?
Mike F: MarkupResponse includes markup scope (User, Producer, refHandle, Registration). Invalidation tag prefix returned by Producer in interactionResponse to invalidate content. Consumer matches prefix “slice” into cached content.
See Yossi’s email of 9/30 for details
Gil: This is an attempt to mirror http-based caching we have today, plus adds invalidation.
Andre: Concern that the invalidation tag prefix mechanism will be difficult for developers to code to.
Mike F: When used properly, it’s very performant.
Sasha: If Producer uses the invalidation scheme, the Consumer MUST adhere to it. That’s going to be complicated.
Rich: That’s actually true of any optional (i.e. beyond expiry) caching scheme the Producer is using…Consumer MUST adhere to it.
Eilon: Registration meta-data will help to inform Consumer what it has to do.
Thomas: No micro-flags for fine-grained cache control. All or nothing. Should simplify Producer implementations.
Mike F: So what’s more elemental (in terms of industry usage today) is pure expiry, or expiry + validation (eTags). For a Producer that wants to be extremely performant (i.e., a “home page” portlet), an invalidation mechanism would be nice to have, although that’s certainly a more complicated scheme for the Producer to implement.
Rich: Could a Consumer that wants to do invalidation-keying signal its capability to the Producer?
Gil: Invalidation seems like a v2.0 consideration.
How “sticky” is navigationalState? Or, how long does the Consumer need to remember navState?
Mike F: Understand maintaining state within the context of the aggregated unit.
This is related to the question of the Consumer MUST remember the last navState, in the event no navState gets returned in an InteractionResponse. Does this potentially imply Consumer session?
Gil: No, null navState is an “alias” for “give me what I sent last time”.
The other question is what the meaning of null navState in InteractionResponse means? Must it always mean the Consumer manages the navState between invocations?
Mike F: There are useful scenarios for this to actually mean “null” or no state.
Eilon: Make it a required field, so “null” is no longer available. So, return “empty” to signify no state.
Slide depicting various property structures.
Gil: The “reset” attribute on Property doesn’t make sense for getProperty()?
Bruce: May just want a separate interface to reset properties to default.
Gil: for getEntityProperties, the signature includes a propertyList. No reason to include property values in this call.
Charlie: Don’t recall why the working group chose this, but it should be ok to revert to a list of names.
Looking at proposal for <wsrp:localization/>
Bill: Why are we inventing a WSRP version of resource localization? Are there other standards that we should be waiting on?
Charlie: How can we go out without support for internationalization in 1.0?
Mike F: Vendors already have internationalized products, so for us to propose spec that doesn’t permit portlets to make use of this capability is a non-starter.
Rich: Summary of the open questions, and we’ll vote later in the week:
Atomic..but not transactional.
Carsten: Difference between atomic and transactional?
Bruce: Use case for atomicity of property changes? All-or-nothing truly required?
Rich: Consumer-managed properties, especially if they’re a hierarchy, is one.
Mike F: So, “synchronized” may be a better term.
Rich: Validated and synchronized update, not required to be transactional.
Gil: It’s potentially too large, not all Consumers need/want property description whenever they get an entity description.
Bill: Maybe we should consider the general problem of specifying (micro flags?) what should be included in the response to any request.
Rich: Our approach has been that unless TC folks indicate something really is mandatory in a given resposne, then it gets separated (with separate API to retrieve it).
Mike F: Don’t understand ‘wsia:refHandle’. The spec already mandates that the Consumer has to return the refHandle on all requests, so why does it belong in the Producer-rewritten URL?
Andre: Wondered why this wasn’t entityHandle?
Mike F: It’s not specific enough.
Rich: Consumer needs to supply the indirection of refHandle, since it can change on a getMarkup.
Consumer needs to know what the character encoding of the parameters is.
Mike F: Suggested solution is to mandate that encoding, UTF-8. Consumers will therefore always know what the answer is.
Gil: This isn’t important for Consumer URL rewriting?
Mike F: Not always true, there are places where the Consumer requires the Producer to do URL encoding.
2 proposed mechanisms:
1. Mandate: UTF-8
2. URL itself carries the information. Add a token, ‘charset’, that the Producer re-writes with the encoding.
Sasha: Dislike #2. You need to parse the URL to find the charset. Not normal behavior that off-the-shelf parsers will take advantage of.
Gil: So #2 could really be viewed as a Boolean. Either the markup is returned in UTF-8, or it wasn’t.
Mike F: Correct, although you lose the particular charset in use.
Vote: 1: 17 2: 1 Abstain: 5
Mike F: Think it’s natural in markupParams.
Resolved: Yes
urlType==resource, so it’s an embedded URL. Problem is conflicting levels of encoding.
Rich: If we change verbiage to mandate “strict” URL encoding, then double-encoding isn’t needed.
Resolved: Producer does strict encoding (i.e. make it a valid query string value … encode ‘&’, ‘=’, ‘?’, ‘:’, ‘/’ and ‘?’).
Mike F: For both Producer and Consumer URL’s?
Rich: Since it’s the template that’s being replaced, the Producer must always do this.
Efficient parsing.
Sasha: Enforcing an ordering could be a problem for debuggability.
Mike F: Not a debugging issue, since if it’s missing it’s easily logged/found.
Rich: Suggest: /wisa:rewrite?urlType&wsia:url…
Resolved.
Gil, Sasha: What is requestParameters again? Isn’t this navigationalState?
Rich: It’s where the Producer puts any “extra” query string parameters.
Gil: So these shouldn’t be double-encoded.
Resolved: Change ‘doubly’ to ‘strictly’.
Switch to ‘XXX-‘
What XXX will be is for Friday.
Lingering issue: What are the semantics of the Consumer refusing to change window state?
Mike F: Some confusion over window states…is it a state? Or is it a style?
Rich: It’s a state that implies a style.
Mike F: Consumer refuses, then it should immediately call getMarkup.
Gil: How typical would it be for the Consumer to refuse a state?
Mike F: If the Consumer receives a request for a state it doesn’t support.
Sasha: This seems very unlikely to occur. Leads to complexity on both Producer and Consumer.
Resolved: Drop Config
URI’s are encouraged.
Gil: The standard roles, modes, window states aren’t URI’s. We’re not eating our own dog food.
Resolved: Leave as is.
Sept F2F said No. We’ve also changed cloneEntity to take an entityHandle, and not a refHandle.
Mike F: So, should we recast this into “should an entity’s transient state be cloneable”?
Rich: Separate issue.
Resolved: No, per 105 below.
Mike F: Should it take an array of refHandles?
Resolved. ReleaseRefHandles(refHandle[], registrationContext)
Vote: Yes: 11 No: 8 Abstain: 5
Not-present voters will have a chance to vote next week.
Eilon: Not well named. It’s the underlying entity that gets cloned, and a new refHandle gets created to reference it.
Discussion regarding the use of cloning transient state. Consumer manages property changes, user edits an entity, and entity gets cloned: should also “clone” (really, transfer) the refHandle to the new clone so that the user’s current runtime state is preserved.
Resolved: Not in this version.
Proposals:
Mike F: What are the use cases for supporting GET at all?
Sasha: The fact that it does have different behavior then POST, and it’s heavily used today (e.g. Google).
Yossi: We will encourage Producers to use POST?
Rich: Yes.
No.
Yes.
Mike F: Redirect means ignore every other param in the response. Unconventional.
Andre: .NET doesn’t honor faults, or at least not very well. It would not be usual to carry useful data like the redirect URL in a fault.
Rich: The suggestion really boils down to dividing the InteractionResponse.
Mike F: Proposed SOAP fault only as a means of illustrating the issue.
Sasha: You’re also supposed to send back content that could be displayed.
Resolved: Divide InteractionResponse into a choice: normal semantics or redirectURL.
(Does anyone really need new mode, new window state, etc., along with a redirectURL?)
Language suggestion: [see slide]
userProfileExtensions, consumerExtensions, registrationProperties in RegistrationData
registrationProperties in ServiceDescription.
Mike F: These could just live as standard extensions, and the fields should be removed.
Yossi: Makes life a bit more difficult, since Consumer now has to hunt for entity’s extended user profile attributes (for example) in the extensions.
Rich: consumerExtensions was brought up long ago, not sure anyone has found a real use for it.
Charlie: registrationProperties appear to be very close to wsdl endpoint properties. We need to be clear that they are not.
Resolved: ServiceDescription.registrationProperties of type ModelDescription
Drop consumerExtensions.
Mike F: Rename userProfileExtensions to remove the “extension”. (customUserProfileData?)
Mike F: Human-readable description? This should be an extension.
Resolved: Leave as String[].
Add “:”
See 0.8 draft, email suggested changes to Rich.
Keep as is
Two different ones (secure/unsecured)
For case where Producer rewriting requires templates, but Consumer didn’t pass any.
Mike F: Doesn’t seem useful for 1.0 timeframe.
Rich: Either Consumer sends defaults, or the full list of templates (MUST)
Resolved: Separate document to provide guidance to implementers.
Keep ‘Action’ as a synonym for ‘Interaction’.
Mike F: We also need a term for “portlet instance” based on yesterday’s decision to optionally carry a portlet ID.
If there’s no user ID, what’s the value of carrying the GUEST role?
Mike F: This is a role that applies to this user, regardless of the portlet he uses.
Alej: Can a profile key be shared by multiple users?
Yes.