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 (on leave) |
WebCollage |
|
Gil Tayar |
WebCollage |
y |
Prospective Members
(non-voting) |
|
|
Dan Machak |
Tibco |
|
WSIA Members (non-voting) |
|
|
Graeme
Riddell |
Bowstreet |
|
Bruce
Lucas |
IBM |
|
Ravi
Konuru |
IBM |
|
Dan Gisolfi
|
IBM |
|
|
|
|
Welcome
Elect new secretary
Vote on remaining technical issues, so editors can create 0.9 specification
Need host for January F2F, West coast. (Friday)
Introductions
Focus on these first, so that Stefan (other JSR lead) can participate.
Alej: Can we use the approach suggested by the JSR spec leads’ email, that breaks these into three broad topics?
Mike F: Certain callers have made themselves available for issue 133, so we should start with that one…then suggest the approach in the email.
Rich: Array of <any>, structure pushed in a level for interop with JAX-RPC reference impl.
Alej: Will WSRP define suggested schema for String and String[]?
Rich: Yes
Alej: Then JSR has no problem with the mechanism.
Mike F: We want String[] and PropertyList (name-values).
Rich: Both are in the current wsdl. The schema will become a separate file that gets imported.
Rich asks David (Oracle) for his thoughts on <any> element: JAX-RPC requires <any> element gets wrapped in a grouping element. Otherwise, happy with the idea of XMLSchema for typing.
Andre: <any> doesn’t give any interop. Really limited to manipulating them as XML elements, and parsing.
Gil: But that’s true of any extensibility mechanism. Issue 133 seems settled?
Mike F: We had a discussion on Thursday about modifying the structure of <any>.
Gil: That’s issue 93.
Rich: Another open question: how many vendor implementations inherit the JAX-RPC RI’s limitation with respect to <any> deserialization? We should keep the indirection in the extension structure.
David: The wrapper element could be nillable? MinOccurs=0 may be a better choice.
Andre: Because the style of wsdl we’re using, nillable elements could be skipped by certain stacks (.NET?) during proxy generation.
Gil: What is the reason for nillable? Use minOccurs=0 to define something is optional.
Rich: These sorts of refinements are being worked out by a sub-group.
Alej: JSR defines no required user attributes. A portlet can expose various named user attributes, that must then be mapped by a portal. If the extension is <any>, custom deserializer required.
Carsten: No custom programming...you could use XPath to traverse the XML.
Gil: The difficulty here is that WSRP is taking a document/literal approach, and Alejandro wants a ‘pure’ rpc approach.
Rich: At a philosophical level, this is the basic question for all three of these issues. Consensus seems to be that we leave things as is.
Mike F: JSR and WSRP approaches are not mutually exclusive.
Carsten: The JSR also uses this for determining cacheability?
Mike F: Let’s not focus too much on specific JSR functionality. JSR is an external “reviewer” of this spec.
Gil: This seems difficult, if not impossible, for WSRP. Consumer semantics cannot be easily transmitted to the Producer (without a full XACML).
Mike F: Disagree that this is not representable. Do we want 3rd party vendors to just use extensibility?
Gil: What’s the proposal?
Rich: (from slide) two independent arrays, allowable window states and allowable portlet modes.
Alej: If arrays aren’t present, then implied semantic is all modes/window states are allowed.
Mike F: Producer meta-data indicates cacheability in the session?
Thomas: These aren’t likely to change often, so caching makes sense.
Sasha: Is this a MUST for the Producer? If not, don’t understand the need for this.
Mike F: The point is to narrow the choices the Producer makes at the point of the request. The spec already states that the Consumer can reject any requested mode/window state transition.
Raj: Producer can choose to return any combination of mode/window state from request to request.
Mike F: Yes.
Sasha: This seems confusing, since we’re agreeing to different semantics for JSR and WSRP.
Mike F: True interop will require that the information gets passed. However, this doesn’t need to be specified, it’s more of an implementation guide.
Add arrays to MarkupParams. Add entity metaData. Shoulds => assist in generating UIs valid for the End-User.
Thomas: Only state changes would be allowed that don’t affect other WSRP entities.
Mike F: JSR represents actions as blocking, non-blocking. Non-blocking action is folded into the render phase. WSRP has only blocking actions.
Rich: Does a non-blocking action return modified navigational state?
Mike F: No.
Rich: Then Producer could deterministically map between two action protocols. (Option 2 on the slide).
Many: What’s the use case for this?
Mike F: JSR has determined that you can only dispatch to a servlet/jsp from getMarkup. This is in addition to the efficiency question.
Andre: This is also important for legacy considerations.
Gil: I still don’t understand the reasoning.
Mike F: JSR is designed so that servlets/jsp’s can only be executed from a getMarkup. So, render() was designed to model both non-blocking actions as well as rendering.
Gil: What is a non-blocking action?
Mike F: An action that only changes navigational state. So the first level optimization would be to allow performInteraction to return markup. The next level would be to introduce a new operation (“performNonBlockingAction”?), which would be parallelizable.
Rich: This would also require distinction between blocking and non-blocking action urls.
Mike F: If markup is being returned, then Consumer MUST ignore navState, mode/window state, etc. Producer SHOULD set these to null.
Gil: We should draw a 2x2 matrix: Affects Consumer (Y/N) x Affects Other Entities (Y/N)
Rich draws 2x2 matrix to represent the different
approaches.
Yossi: What is the reason for restricting mode, window state, etc?
Mike F: Because the Consumer may not be in a state that permits a mode/window state transition. Besides, there’s benefit to being overly restrictive in the beginning, and we can relax these later.
Rich: Let’s stop here, and move on to the selection of a new secretary.
Rich and Mike will work up the various proposals.
Mike F: We should agree in principle to support non-blocking actions, and the leave the question of ‘how’ until we see the various detailed proposals. JSR wants to release a new spec at the end of the week, and this is a critical issue.
Rich: Consensus appears to be in favor, so JSR should proceed. We’ll look at the detailed proposals tomorrow.
Steven Smith has graciously volunteered.
Alej: This is dependent on the outcome of 133.
Gil: Why? Especially if we choose to model non-blocking actions in getMarkup.
Rich: So we can return to this.
Mike: Forwarded a couple of proposals to dimension allowed modes by markupType in the metadata.
Gil: So we’d need to forward this information per request?
Rich: No, this is entity metadata.
Thomas: So this is necessary to permit portal to render the portlet correctly, with proper controls/decorations.
Sasha: Are Consumer-supported modes showing up in multiple locations?
Mike F: This is Producer-supported.
–move metadata into
an array of structures where each
structure is per markupType & contains validModes and validWindowStates.
•String markupType
•String[] modes
•String[] windowStates
•Extension[] extensions
Mike F: Want to defer discussion on this. This is a very similar debate as the question of carrying groupID, and would prefer we settle that first.
Gil: What is this field?
Rich: Consumer sending information about itself to the Producer.
Mike F: Major (only?) use case here is for sending information about an extension.
Gil: rename to consumerAgent.majorversion.minorversion.
Sasha: Should explicitly state in the spec that there is no compatibility implied by the version numbering.
•rename to consumerAgent
•productname.majorversion.minorversion other_words
Rich: Goes over the 0.8 tri-state entityStateChange semantic.
Mike F: Fault followed by retry is no longer required? JSR would want a way to signal that it didn’t want to receive a fault if this was the semantic.
Rich: That is correct, as of 0.8.
Mike F: Then the JSR would be satisfied with this as the resolution.
Gil: What is the use case for this?
Mike F: There are portal vendors who already have this capability in their products.
Sasha: Like a links portlet, and new links are added as new properties.
Mike F: Should there be a return indicating that the model has changed?
Rich: That seems like a backdoor to eventing.
Bruce: The statement in the spec regarding completeness of the model description should really address how the desire to make it as ‘static’ as possible.
Gil: There was no email commentary on 119.
Gil: These should be namespaced to the specification.
Rich: But these are values…but you namespace the tags.
Sasha: Values should be QNames.
Andre: See this as more of an issue for the customized ones.
Gil: It would be complicated to require namespacing for values. Not sure about consistent stack support.
Sasha: It would be better for extensibility. Would like to vote?
Change values for modes/window states to QNames?
Yes: 7 No: 10 Abstain: 5 Not Present: 3
Sasha: Would rather go with something more specific to WSRP. ‘markup-‘ is too generic.
Thomas: ‘fragment-‘?
Mike F: What about ‘portlet-‘? ‘markup-fragment’?
‘fragment-‘
Andre: Wanted hints
Rich: better defined semantics.
Mike F: Pending discussion of new action model
Alej: the set of possible types is extendable?
Rich: Yes
Rich: In markupParams
Yossi: Present wording in section 10.2 is ok, might want to change SHOULD (require end-user to supply identification…) to MAY.
Rich: No objections.
Mike F: Why ‘require’? Shouldn’t it be ‘request’?
Rich: Particularly if it becomes MAY.
Mike F: Carrying user ID in the protocol is still very ambiguous.
Rich: Currently carried as profile key.
Mike F: Does the spec give enough semantics for Producers to reliably establish user identity?
Yossi: We said we’d use WS-I for this.
Mike F: Not yet available. In the interim, it would be better for us to more tightly define this. Such as a Principal ID.
Yossi: Conceptually, such a Producer is operating in an extended manner.
Sasha: What Mike wants is a key that’s tied to LDAP, or some other external system?
Mike F: My basic question is whether the Producer has access to the Consumer’s authenticated user ID. Effectively, the answer right now is no. The Consumer is free to send anything it wants, according to the spec. So why should the spec say anything about user ID now? Just rely on vendor extensions for now, and eventually standards (SAML, etc) will catch up.
Yossi: (in response to proposed renaming to principalID). Think it’s unwise, there’s some debate about the meaning of principalID.
Sasha: Agree with Yossi. Also, we also use ‘profile’ extensively.
Alej: But this is not interoperable.
Mike F: Since it’s part of the userContext, why not just call it ID?
Rename to ID, remove extra verbiage.
Rich: Currently no such operation. If we want to have it, it would go in the markup portType
Mike F: Not in this version. Want to see justification…why wouldn’t timeouts handle the cleanup of old transient state?
Andre: Disagree.
Mike F: Not really opposed to its inclusion, other than this adds additional implementation. Spec should be clear as to what effects on the entity, if any. Would look a bit better anyway, since most refHandle operations end up being side-effects.
Rich: Would prefer we wait until our in-depth discussions tomorrow.
Gil: Even if relationship is created out-of-band, this context still exists.
Mike F: We don’t require registration. Nor do we require that a Producer somehow distinguish between different Consumers.
Rich: Could be that the scoping here is really to the Producer. If an optional registration context exists, then that could be the narrower scope.
Raj: Why would a Consumer need to worry about registering with a simple service?
Rich: It wouldn’t. This issue was raised relative to the entityHandle returned by cloneEntity().
Add language for the no-registration case
Rich: Default==Fault leads to a great deal of work.
Mike F: ‘Fault’ is easier to debug. ‘OK’ could mask bad writes. But everyone will be setting this explicitly anyway.
Andre: ‘OK’ as default is the common runtime case.
Rich: We could make this required, and have no default. Force an explicit setting.
No default, force explicit setting
Rich: We may revisit this, and add an operation that refers to session clone.
Gil: Disagree here, we’re closing the door on a whole set of legacy applications. If the Producer is url-rewriting, then it could do GET forms, encode hidden fields. If Consumer is url-rewriting, then it wouldn’t be possible, so those apps need to be re-implemented.
Rich: What you’re asking for is a statement that describes the consequences for implementers?
Sasha: If the Consumer is ‘well-behaved’ and encodes its params before the query string, then GET is supportable.
Yossi: Would like to analyze this better, and truly distinguish supportable from un-supportable uses of GET.
Rich: The Consumer has to help out by declaring its urls are GET safe.
Rich: Should add paragraph to section 9 describing difficulties in using method==get and registrationData field for methodGetSafe.
Gil: It will be difficult for the Consumer to pre-determine that it’s GET-safe, so why have this metadata?
Yossi: Encoding params in the path isn’t good HTML practice.
Sasha: That’s only one proposed solution. There are other solutions (e.g., morph to POST), so there is no reason for the spec to disallow GET forms.
Gil: Registration is optional, so how does a Producer get this metadata from unregistered Consumer? This is a more general problem, not just related to GET safe.
Rich: If this is required information, then in-band or out-of-band the information needs to be conveyed to the Producer.
Andre: Wouldn’t it make more sense for this to be entity metadata anyway? (e.g. usesMethodGet)
Joe: Doesn’t adding more metadata like this (i.e. flags to signify different types of behavior) make interoperability more complicated?
Sasha: Short answer: Yes.
Andre: To maximize interop, use POST.
Entity metadata to indicate it sends back GET: 6
Require consumers to make method GET safe: 6
GET shouldn’t be there: 1
Thomas: It would be ideal for Producers to use POST.
Sasha: One of the benefits of GET is for bookmark/refresh.