Voting Members |
Company |
|
|
Stephen Drye |
Art Technology Group |
y |
|
William Cox |
BEA |
y |
|
Adrian Fletcher |
BEA |
y |
|
Gino Filicetti |
Bowstreet |
y |
|
Andre Kramer |
Citrix |
y |
|
Monica Martin |
Drake Certivo |
y |
|
Timothy N. Jones |
CrossWeave |
y |
|
Alan Kropp |
Epicentric |
y |
|
Nigel Ratcliffe |
Factiva |
y |
|
Madoka Mitsuoka |
Fujitsu |
y |
|
Carsten Leue |
IBM |
y |
|
Thomas Schaeck, chair |
IBM |
y |
|
Rich Thompson |
IBM |
y |
|
Charles Wiecha |
IBM |
y |
|
Eric van Lydegraf |
Kinzan |
|
|
Jon Klein |
Reed-Elsivier |
y |
|
Adam Nolen |
Reed-Elsivier |
y |
|
Petr Palas |
Moravia IT |
y |
|
Mark Cassidy |
Netegrity |
y |
|
Olin Atkinson |
Novell |
|
|
Chris Braun |
Novell |
y |
|
T.J. Cox |
Novell |
y |
|
Michael Freedman |
Oracle |
y |
|
Mike Hillerman |
Peoplesoft |
|
|
Sasha Aickin |
Plumtree |
y |
|
Jane Dynin |
Plumtree |
y |
|
Joseph Stanko |
Plumtree |
|
|
Michael Young |
Plumtree |
y |
|
Amir Blich |
SAP |
y |
|
Gennady Shumaker |
SAP |
y |
|
Yossi Tamari |
SAP |
y |
|
Brian Dirking |
Stellent |
y |
|
Alejandro Abdelnur |
Sun Microsystems |
y |
|
Dave Clegg |
Sybase |
y |
|
Joe Rudnicki |
U.S. Navy |
|
|
Eilon Reshef |
WebCollage |
|
|
Gil Tayar |
WebCollage |
y |
|
Rex Brooks |
individual |
y |
|
Steven Smith |
|
|
|
Raj Ramesh |
|
y |
|
Prospective Members
(non-voting) |
|
|
|
Richard Cieply |
IBM |
|
|
Art Machado |
|
|
|
Ken Pugsley |
|
y |
|
Sunit
Randhawa |
|
y |
|
WSIA Members (non-voting) |
|
|
|
Bruce
Lucas |
IBM |
y |
|
Ravi
Konuru |
IBM |
|
|
Graeme
Riddell |
Bowstreet |
y |
|
|
|
|
|
|
|
|
Minutes for 10/17 accepted
Starting at 10am on Monday
Rex: Are call-in numbers available yet?
Thomas: three meetings this week. Summarized to lists. Asks Alejandro, Carsten and Rich to discuss.
Alej: Need agreement on a few items for interop.
WSRP allows state change only in performInteraction. JSR doesn’t have this restriction.
Rich: WSRP could allow state changes in getMarkup, or the Producer could “mask” the issue through caching.
Mike F: The second is impractical. Would require all URL’s are action URL’s, which isn’t acceptable.
Alan: Is the intent to attempt to solve these in this call?
Producer is permitted to handle properties that aren’t published in the entity description. Believe this can be handled through entity opaque state.
Alej: Can dynamic properties be modified through setEntityProperties?
Rich: No. Only exposed properties can be modified in this manner.
Charlie: Would like to cycle this back to next Wednesday’s property call.
WSRP allows any type for property value. Not a JSR issue since the WSRP type is a superset
WSRP does not have this attribute for properties. But the extension mechanism could be used to carry this.
Another solution was to expose only modifiable properties, based on user context.
Ongoing JSR discussion, so this can be revisited later.
Bruce: Would be nice to understand the use cases better.
JSR is far from consensus on this, so not an issue for now.
Allow Producer to provide private scope mapped to a particular entity on a page (window).
WSRP sends entityHandle on initial page view, the Producer at that point can encode the window ID in the refHandle.
Mike F: Don’t want to have to use the refHandle for this. It should be passed over as add’l data, from the Consumer
Gil: Goes back to old discussion. RefHandle was intended for just this sort of possibility.
Mike F: No. This will lead to performance/scalability problems.
Rich: Instead of encoding it in the refHandle, could encode it as a cookie.
Mike F: Cookies could get quite large. Would prefer we pass it explicitly in the protocol, or the JSR decides on a suitable extension for WSRP interop.
Bruce: Consumer-managed refHandle. Consumer encodes the window ID.
Carsten: Doesn’t this blur the refHandle? We had agreed that refHandles are always Producer-managed.
Mike F: We should open an issue for discussion.
Alej: And JSR should discuss possible extension.
Concern with “wsia:” prefix. Propose “portlet:” instead.
Charlie: “markup-fragment”?
Chris: That would be very long. The class names themselves are long enough.
Rich: we should open an issue, this has been on the backburner for a while.
Thomas: “markup:” as a placeholder?
JSR allows string name-value’s. WSRP allows <any/> schema elements. WSRP should adopt name-value’s as well.
Should still be possible for JSR to come up with protocol extensions to handle WSRP extensibility (DOM parsing, etc.).
Charlie, Carsten: Would all JSR portlets then essentially require this extensibility for WSRP compliance?
Thomas: Would like a proposal that achieves interoperability without requiring a protocol extension.
Mike F: As an intermediate proposal, we could use the property arrays in getMarkup/performInteraction, since they’re string name-values anyway, and then the return structures would need to include a response property list array.
Charlie, Bruce, et al: Why not define a content model that allows JSR to interpret the <any> as string name-values?
Mike F: The problem with the <any> model is that it’s not a Least Common Denominator approach.
Bruce: It’s pretty trivial to carry string name-values in the <any> element.
Rich will write up a resolution.
WSRP doesn’t convey allowed modes/states in getMarkup/performInteraction.
Carsten: In WSRP, the mode is completely managed by the Consumer.
Alej: But what about when the portlet is finished in one mode, eg. Edit, and needs to transition back to View?
Rich: We don’t want to reinvent XACML
Carsten: Why not allow the portlet to manage mode/window state change?
Alej: It doesn’t have all of the information, ie, current interaction context, that the Consumer does.
Thomas: Portlet could generate markup for a given mode/window state, and Consumer is free to reject it, and resubmit a request for the correct mode/window state.
Alej: That could break transactions. When Consumer resubmits, previous info could be lost.
Mike F: We should move on, with 10 minutes remaining.
JSR does simple expiry caching. Waiting to see outcome of WSRP caching discussion.
Waiting on WSRP discussion.
Have proposed that WSRP simplify the names (issue submitted)
J2EE 1.4 will use the HTML xml-lang attribute.
Gil: This complicates rpc-style interface development
Rich: We already can’t do rpc-style due to prior problems.
JSR could have an appendix of common name mappings.
WSRP expresses user attributes as structured data. JSR will have to deconstruct this into name-values.
JSR allows upload data in both performAction/render…WSRP only allows this in performInteraction. Related to action issue
JSR allows for modes by contentType. WSRP does not distinguish allowed modes this way.
Rich: Does this come from the entity description?