wsia message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Subject: [wsia] F2F Minutes 11/4 (Website version)
- From: Rex Brooks <rexb@starbourne.com>
- To: wsia@lists.oasis-open.org
- Date: Mon, 18 Nov 2002 05:53:31 -0800
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