OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsia message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: [wsia] F2F Minutes 11/4 (Website version)


Title: F2F Minutes 11/4 (Website version)
Monday, 11/4/02
Roll
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
JSR/WSRP sync
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.
Refer to F2F slide presentation for discussion points on the following issues
#133 extensions typing (correlated 93, 121)
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.
#121 user info extension
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. 
Mark 133, 93, 121 resolved. 
#132 Valid portlet modes/window states
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.
Resolution
Add arrays to MarkupParams. Add entity metaData. Shoulds => assist in generating UIs valid for the End-User.

#122 Action definition mismatch (#94, 143a)
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.
New Secretary (through the next F2F)
Steven Smith has graciously volunteered.
#126 upload data in both markup operations
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.
#123 portlet modes per markup
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.
Resolution
-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
#124 window ID
 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.
#152 consumerVendor field format
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.
Resolution
*rename to consumerAgent
*productname.majorversion.minorversion other_words

#125 clone-on-write
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.
#127 setting properties not defined in type definition
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. 
#119 Naming of modes and window states (#136)
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?
Vote
Change values for modes/window states to QNames?
Yes:  7  No:  10  Abstain:  5  Not Present:  3
Resolution
       Drop redundant portion
Make lower case

#115(2nd) 
Sasha:  Would rather go with something more specific to WSRP.  'markup-' is too generic.
Thomas:  'fragment-'? 
Mike F:  What about 'portlet-'?  'markup-fragment'?
Resolution
'fragment-'
Pending resolutions
19 initEnvironment verbiage
Andre:  Wanted hints
Rich:  better defined semantics.
23 markupParams has requestParams
Mike F:  Pending discussion of new action model
84 Add string clientAuthType
Alej:  the set of possible types is extendable?
Rich:  Yes
90 when do templates get sent to Producer
Rich:  In markupParams
104 Multiple means of Consumer supplying profile ID
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?
Resolution
Rename to ID, remove extra verbiage.
105 releaseRefHandle?
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.
106 entityHandle definition within registration context
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().
Resolution
Add language for the no-registration case
108 entityStateChange defaults to OK
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.
Resolution
No default, force explicit setting
109 clone-on-write refers to entityHandle
Rich:  We may revisit this, and add an operation that refers to session clone.
115 GET forms disallowed in markup where there's url rewriting
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.
Straw vote:
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.

     

--
Rex Brooks
Starbourne Communications Design
1361-A Addison, Berkeley, CA 94702 *510-849-2309
http://www.starbourne.com * rexb@starbourne.com


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC