| [Thread Prev]
| [Thread Next]
| [Date Next]
| [Thread Index]
| [Elist Home]
Subject: [wsia] F2F Minutes 11/4 (Website version)
- From: Rex Brooks <email@example.com>
- To: firstname.lastname@example.org
- Date: Mon, 18 Nov 2002 05:53:31 -0800
Title: F2F Minutes 11/4 (Website
Stephen Drye (on
Steven Smith Capitol College y
Andre Kramer Citrix y
Madoka Mitsuoka (on
Carsten Leue IBM y
Eilon Reshef (on
Vote on remaining
technical issues, so editors can create 0.9 specification
Need host for January
F2F, West coast. (Friday)
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
Refer to F2F slide
presentation for discussion points on the following
typing (correlated 93, 121)
Rich: Array of
<any>, structure pushed in a level for interop with JAX-RPC
Alej: Will WSRP
define suggested schema for String and String?
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
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.
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
Mike F: We had a
discussion on Thursday about modifying the structure of
Gil: That's issue
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
David: The wrapper
element could be nillable? MinOccurs=0 may be a better
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
Rich: These sorts
of refinements are being worked out by a sub-group.
#121 user info
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
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
Mark 133, 93, 121
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
Mike F: Disagree
that this is not representable. Do we want 3rd party vendors to
just use extensibility?
Gil: What's the
Rich: (from slide)
two independent arrays, allowable window states and allowable portlet
Alej: If arrays
aren't present, then implied semantic is all modes/window states are
Mike F: Producer
meta-data indicates cacheability in the session?
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
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
Mike F: Yes.
Sasha: This seems
confusing, since we're agreeing to different semantics for JSR and
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
Add arrays to
MarkupParams. Add entity metaData. Shoulds => assist in generating
UIs valid for the End-User.
definition mismatch (#94, 143a)
state changes would be allowed that don't affect other WSRP
Mike F: JSR
represents actions as blocking, non-blocking. Non-blocking
action is folded into the render phase. WSRP has only blocking
Rich: Does a
non-blocking action return modified navigational state?
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
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
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
Rich: This would
also require distinction between blocking and non-blocking action
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
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
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
appears to be in favor, so JSR should proceed. We'll look at
the detailed proposals tomorrow.
(through the next F2F)
Steven Smith has
#126 upload data in
both markup operations
Alej: This is
dependent on the outcome of 133.
Especially if we choose to model non-blocking actions in
Rich: So we can
return to this.
#123 portlet modes
a couple of proposals to dimension allowed modes by markupType in the
Gil: So we'd need
to forward this information per request?
Rich: No, this is
Thomas: So this is
necessary to permit portal to render the portlet correctly, with
Consumer-supported modes showing up in multiple
Mike F: This is
into an array of structures where each structure is per
markupType & contains validModes and
Want to defer discussion on this. This is a very similar debate
as the question of carrying groupID, and would prefer we settle that
Gil: What is
sending information about itself to the Producer.
Mike F: Major
(only?) use case here is for sending information about an
Gil: rename to
explicitly state in the spec that there is no compatibility implied by
the version numbering.
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
Rich: That is
correct, as of 0.8.
Mike F: Then the
JSR would be satisfied with this as the resolution.
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
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.
statement in the spec regarding completeness of the model description
should really address how the desire to make it as 'static' as
#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.
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
rather go with something more specific to WSRP. 'markup-' is
Mike F: What about
Pending discussion of new action model
84 Add string
set of possible types is extendable?
90 when do
templates get sent to Producer
104 Multiple means
of Consumer supplying profile ID
Present wording in section 10.2 is ok, might want to change SHOULD
(require end-user to supply identificationŠ) to MAY.
Mike F: Why
'require'? Shouldn't it be 'request'?
if it becomes MAY.
Mike F: Carrying
user ID in the protocol is still very ambiguous.
carried as profile key.
Mike F: Does the
spec give enough semantics for Producers to reliably establish user
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.
Conceptually, such a Producer is operating in an extended
Sasha: What Mike
wants is a key that's tied to LDAP, or some other external
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'
Alej: But this is
Mike F: Since
it's part of the userContext, why not just call it ID?
Rename to ID,
remove extra verbiage.
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?
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.
definition within registration context
if relationship is created out-of-band, this context still
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
Raj: Why would a
Consumer need to worry about registering with a simple
wouldn't. This issue was raised relative to the entityHandle
returned by cloneEntity().
Add language for
the no-registration case
entityStateChange defaults to OK
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
No default, force
refers to entityHandle
may revisit this, and add an operation that refers to session
115 GET forms
disallowed in markup where there's url
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
Rich: What you're
asking for is a statement that describes the consequences for
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?
params in the path isn't good HTML practice.
only one proposed solution. There are other solutions (e.g.,
morph to POST), so there is no reason for the spec to disallow GET
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.
it make more sense for this to be entity metadata anyway? (e.g.
adding more metadata like this (i.e. flags to signify different types
of behavior) make interoperability more complicated?
Sasha: Short answer:
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
Thomas: It would be
ideal for Producers to use POST.
Sasha: One of the
benefits of GET is for bookmark/refresh.
Starbourne Communications Design
1361-A Addison, Berkeley, CA 94702 *510-849-2309
http://www.starbourne.com * email@example.com
| [Thread Prev]
| [Thread Next]
| [Date Next]
| [Thread Index]
| [Elist Home]
Powered by eList eXpress LLC