Meeting started at 8:05 PST
====================================================================
Roll Call
Voting Members:
---------------------------------
Alejandro
Abdelnur
Sun
no
Sasha
Aickin
Plumtree
no
Subbu
Allamaraju
BEA
yes
Olin
Atkinson
Novell
yes
Atul
Batra
Sun
yes
Amir
Blich
SAP
yes
Michael
Bosch
Vignette
no
Rex
Brooks
Starbourne
yes
T.J.
Cox
Novell
no
William
Cox
BEA
no
Brian
Dirking
Stellent
yes
Michael
Freedman
Oracle
yes
Ross
Fubini
Plumtree
yes
Richard
Jacob
IBM
yes
Jon
Klein
Reed-Elsevier
no
Andre
Kramer
Citrix
yes
Alan
Kropp
Vignette yes
Carsten
Leue
IBM
no
Dan
Machak
Tibco
yes
Nigel
Ratcliffe
Factiva
no
Thomas
Schaeck
IBM
no
Gennady
Shumaker
SAP
no
Steven
Smith Capitol
College yes
Yossi
Tamari SAP
yes
Rich
Thompson
IBM
yes
Charles
Wiecha
IBM
yes
Total voting
members: 26
Voting members in attendance: 16
(62%)
A quorum was present.
Members on Leave Of Absence
----------------------------
Chris
Braun
Novell
LOA (for next 45 days)
Sunit
Randhawa
Fujitsu
LOA
Joe Rudnicki
U.S.
Navy
LOA
Eric van
Lydegraf
Kinzan
LOA
Prospective Members (non-voting):
---------------------------------
Winston
Damarillo GlueCode
Software no
Metin Ergener Vignette no
Noah
Guyot
Vignette
yes
David
Holladay
Microsoft
yes
Dimitri
Jirov SAP
yes
David Raphael Ericsson no
WSIA Members (non-voting):
-----------------------------
Ravi
Konuru
IBM
no
Bruce Lucas IBM no
Graeme Riddell Bowstreet no
====================================================================
Unable to take notes while working with conference
call operator to clear up line noise.
Sorry.
====================================================================
The minutes from the face-to-face
(5/12-5/14) were accepted
====================================================================
1. SC Status/Issues:
Interoperability (Richard)
Conformance (Rich)
[unable to take notes
at this time, missed Rich’s report]
WSDL (Andre)
Will become active in
July
PFB (Alan)
Will become active in
July
Markup (Rex/Andre)
New charter available
for review
Coordination (Rich)
Will become active in
July
Interfaces (Mike)
No activity
anticipated until September
2. Andre’s “to raise” list
-
path encoding URLs using templates (i.e. :/../../ style) requires
producer to avoid special chars (/,:,&,%,*)
-
not possible to clone (and set up a portlet session)) and
re-direct from performBlockingInteraction
-
setProperties returns a portletHandle (implies clone on write?)
-
WS-Security: How to leverage it for user identification and roles?
-
add performInteraction (non-blocking)
3. Outstanding errata (disposition noted
in []’s)
2.1 #16. 5/9/03
(Andre Kramer)
Contact.telecom, Contact.online, Online.uri are not arrays in the IDL.
Should remove the maxOccurs="unbounded" from the WSDL.
Document: WSDL
Section: types
Action: Remove "maxOccurs" attribute from Contact/telecom,
Contact/online, Online/uri
[ACCEPTED]
2.2 #17. 5/9/03 (Andre Kramer)
6.1.17 has UserProfile.bdate while ch 11 has bDate in table. Seems it should be
bdate?
Document: Spec
Section: 11 (twice)
Old Text: bDate
New Text: bdate
[ACCEPTED]
2.3 #18. 5/19/03 (Rich Thompson)
Appendix E (Revision History) had value while the spec was being developed. I
don't think it has value in the final spec.
Document: Spec
Section: Appendix E
Action: Delete this section.
[ACCEPTED]
2.4 #19. 5/13/03 (F2F)
Conformance statement for mode would be better in section 6.8. It should also
be reworded for clarity to the portlet developer.
Document: Spec
Section: 6.1.12
Old Text: The Consumer MAY choose to respect this request to change the mode,
but since the Portlet cannot depend on that choice it MUST NOT encode this new
mode into any of its stateful settings. Rather, the Portlet MUST compute any
such impact on stateful settings after the Consumer has actually changed the
mode.
New Text: See section 6.8 relative to the processing of such requests.
Document: Spec
Section: 6.8
Old Text: Whether or not such a request is honored is up to the Consumer and
often will depend on access control settings for the End-User.
New Text: The Consumer MUST respect requests to change the mode outside of
exceptional circumstances (e.g. access control restrictions), but the Portlet
must not depend on such a request being respected.
[ACCEPTED]
2.5 #20. 5/13/03 (F2F)
Conformance statement for window state would be better in section 6.9. It
should also be reworded for clarity to the portlet developer.
Document: Spec
Section: 6.1.12
Old Text: The Consumer MAY choose to respect this request to change the window
state, but since the Portlet cannot depend on that choice it MUST NOT encode
this new window state into any of its stateful settings. Rather, the Portlet
MUST compute any such impact on stateful settings after the Consumer has
actually changed the window state.
New Text: See section 6.9 relative to the processing of such requests.
Document: Spec
Section: 6.9
Append to first paragraph: Portlets may request window state changes either
through parameters on a link that an End-User activates or by returning a
newWindowState in a BlockingInteractionResponse. The Consumer SHOULD choose to
respect this request to change the window state, but since the Portlet cannot
depend on that choice it MUST NOT encode this new window state into any of its
stateful settings. Rather, the Portlet MUST compute any such impact on stateful
settings after the Consumer has actually changed the window state
[ACCEPTED]
2.6 #21. 5/20/03 (Alejandro Abdelnur)
The namespacePrefix should be required as it may be used by the portlet to
namespace things (ie: javascript thingies) within the generated content. This
is independent from templating.
Document: Spec
Section: 6.1.2
Old Text: [O] string namespacePrefix
New Text: [R] string namespacePrefix
Document: WSDL
Section: wsrp_v1_types.xsd
Old Text:
New Text:
Andre:
This is symmetrical with the required Consumer namespace template if
Producer rewriting.
Mike F:
This sounds like more of a theoretical issue, prefer to wait and see if
experience shows it’s an actual problem.
[DEFERRED
TO EMAIL DISCUSSION]
2.7 #22. 5/21/03 (Alejandro Abdelnur)
Spec doesn't really define the relationship between markup and title. Is title
considered part of cache content? If yes, where does it say that in the spec? I
see assertions like if MarkupContext.useCachedMarkup is true, then
MarkupContext.markupString MUST be NULL. Why doesn't the spec say that
MarkupContext.preferredTitle would be NULL too in this case.
Document: Spec
Section: 6.1.10
Old Text: If the value for useCachedMarkup is “true” the markupString and
markupBinary fields MUST NOT be returned.
New Text: If the value for useCachedMarkup is “true” the markupString and
markupBinary fields MUST NOT be returned. If the value for useCachedMarkup is
“true” the preferredTitle field SHOULD NOT be returned and the previous
preferredTitle value reused.
Mike F: Better to leave
it undefined. We’ll need to be get more
explicit when we introduce invalidation.
[DEFERRED TO EMAIL DISCUSSION]