Going Over Agenda for the Day

Day 2 – May 13

Introduction (Rich)

 Going over agenda for the day

WSRP v.1.1 and v.2.0 Guidelines (Rich)

 v1.1 -- We’ve talked in the past about

No API changes
Some additional markup rules
Publish/Find/Bind added
Leverage attachment mechanisms
Editorial “clean up” of v1

 Bill: the acid test is whether or not folks who did not participate in creating the spec can implement it. Are we looking to incorporate that?

Rich: We’d like to keep stability of the API and incorporate what we find out through implementation
Bill: Great.
Rich: We want a relatively quick cycle to go through small changes
Andre: With P/F/B, we might find that we need API changes. We might have to have a simple publishing mechanism that we extend with API changes later.
Thomas: Are there really ways that PFB would change the API?
Andre: It might add a port type.
Rich: These are not hard and fast rules; this “don’t change the API” is a guideline. If we have to tweak, we can.
Thomas: Cross-compatibility of 1.0 and 1.1 is critical (along with APIs).
Carsten: Will we have backward and forward compatibility?
Rich: You always have to support the basic bindings.

 V2.0 ideas

Additional means to customize markup
Consumer resources?
Means to coordinate interactions among portlets
Transparent transient state (request/session level)
Leverage additional standards where appropriate
Explore invalidation caching (some folks are for, some are against)
Miscellaneous deferred items
Others?

 Alan: Are there going to be any caching mods for 1.1?

Rich: I think it’s hard to do in terms of time and without changing it too much

Deferred Items to Assign (Rich)

 Rich looked through the notes and found deferred items; let’s look at the list and decide:

1.1 vs. 2.0
sub-committee to work on it

 Items:

Markup rules for other markups (Xforms, cHTML, VoiceXML)
For v1.1
Markup SubCommittee
Publish/Find/Bind
For v1.1
PFB SubCom
Semantics of no UserProfile vs. no UserProfile data
Carsten: I don’t think we should deal with the issue of whether it’s the same user
Mike: This is a different question. The question here is whether there is semantics on no UP or no UP data
For 1.1
Resurrect the Interfaces SC for this one
Exploiting attachments
For 1.1
WSDL SC
Exploiting message level security (WS-Security)
For 2.0
Interfaces SC
Align with emerging standards
Remove Registration portType in favor of other standardized portType (Grid?)
For v2.0
Interfaces SC
Coordination
Cross-producer coordination (eventing)
Session-level Properties
For v2.0
Coordination SC
Enhanced Caching
Specifically invalidation caching
For v2.0
Interfaces SC
Customization
Support for Consumer specified controls and control sets
Session-level Properties
For v2.0
Interfaces SC
Refine current spec (all v2.0?)
Portlet offered resources
Leasing of Handles
Returning markup for other place on the page (e.g. page header)
Andre: I would like this to work in v1.1 because of JavaScript in the header
Other folks: We can’t get it done in time for v1.1. It’s too difficult
Consumer controlled grouping Portlet into shared sessions
Portlet hierarchies
For v2.0
Interfaces SC
Fields that were deferred
PropertyDescription.propertyUsage
IsSecure
RewriteRedirectURL
ServiceDesc.version
A bunch more
For v2.0
Interfaces SC
Andre has a list of issues to raise
Exploit WS-Security for user ID and roles
For v2.0
Interfaces SC
Path encoding of URLs using templates requires producer to avoid special chars
For v1.0 (!)
Conformance
Read only properties (both reg and portlet props)
For v2.0
Coordination SC
Clone, set up a session and re-direct from performBlockingInteraction
For v2.0
Interfaces SC
SetProperties should not return a portletHandle
For v2.0
Coordination SC
Add back performInteraction()
For v2.0
Interfaces SC
New property exceptions
UnknownPropertyName
ReadOnlyProperty
For v2.0
Coordination SC
Full negotiation of registration properties:
Current: 2 phase – producer offers; consumer sets
Future? 3 phase – producer offers; consumer requests values; producer sets (values returned to consumer)
For v2.0
Coordination SC
Consumer should communicate mode (& window state?) changes to Producer so Producer can track nav
Alejandro: There is no easy way for a portlet to know that a change has happened, and in both JSR 168 and WSRP, it requires portlet to be built for all states and modes. It’s very difficult. The Consumer should honor the change from the Producer unless there’s an error.
Mike: You’re broadening this item. Some of this is difficult, some is impossible. We might want to wait for implementation issues.
Alejandro: We said we could always bring up issues if they were significant in implementation. I tried to do this in a simple portlet which made it very difficult.
Mike: It’s consistent, but difficult for programmers.
Alejandro: Essentially, this is broken; we need to fix it in v1.0
Rich: Let’s come back to this after the break.
Allow portlet to create a new portlet window (and possibly swap current mode into new window)
For v2.0
Interfaces SC

7 MINUTE BREAK

Navigational State (Rich)

 Alejandro: Statement of problem: since any mode might be called at any point, the navigational state has to have every piece of info needed for every mode

When the mode changes, performInteraction is not called so nav state can’t change

 DavidW: I don’t understand that we can have links that ask for a new mode that isn’t honored. Why can’t we just say that it’s honored?

Rich: This is the same issue of nav state getting out of sync with the mode. We decided not to honor the request because of things like access security
Sasha: I think this is not the same problem, or at least is a broadening of the problem, since we could solve one but not solve the other.
Bill: Let’s get the problem written down clearly before we jump into solutions.

 Rich: Alternative way to get to nav State and mode be out of sync

Activated URL requests mode change and provide a new navState
Consumer decides to not honor mode change request, invokes portlet with different mode and new navState

 Thomas: This is not a problem because navState and mode are orthogonal (mostly).

 Andre: There is also a problem of going back to an old mode. If you go edit  help  edit, is there any sort of stack?

Rich: currently the spec only goes forward, no notion of a stack
Andre: I think this causes a problem of not having a history, and not knowing when to clear this history.

 Rich: Problem arises if the portlet developer presumes a correlation between mode and navState

Mike: and we’ve designed that each portlet has no beginning navState in any mode, which is important to note

 Now, we need to figure out if this is a problem or not.

 Bill: If this makes a major training problem for current developers, then this will be a major problem

 Sasha: Gives e-mail portlet example

 Rich: This comes from our general belief that navState corresponds to URL in a normal web app. Translates over directly for stateless portlets

 Mike: This is a problem not of navStates or sessions; it’s a problem of modes.

 Rich: So web app developers won’t be used to this, but portlet developers will be

 Mike: In our portal, portlet devs do get to always change mode and assume it works; they don’t have to worry about it

 Andre: You can set session variables on getMarkup

 Mike: If you do things in navState, you have to “pre-anticipate” and carry things through in all URLs

 DavidW: My problem is that the Consumer can change the navState but not the mode. That seems wrong

 Sasha throws a fit and becomes incoherent with bewilderment because he thinks none of this makes sense, especially about the use case for not honoring mode change

 Rich focuses us back on the following points:

Everything CAN be done, but it’s just hard.
It will be a chapter in the primer.
Alejandro: the spec does not say that the not honoring of mode change is only in exceptional cases
Mike: There is a case where the portlet will just act as if a session timed out
Stateless portlet is more difficult than stateful portlet.

 The basic issues now boil down to explaining this issue to developers and if we should change the requirement of consumers to MUST for honoring mode change.

Rich: We have primer work and the conformance statement.
Mike: Also, the question of decoration involved.

LUNCH

Calendar for Teleconferences (Rich)

 We discuss times for calls

Tuesday
8 PT
9 PT – PFB (weekly)
Wed
7 PT – WSDL
8 PT – Markup
9 PT
Thursday
8 PT – TC
9 PT – Conformance/Interop

Timeline for WSRP

 Proposal

6/1/2003 WSRP v1 public review finishes
??? – submit v1 to OASIS as standard
10/1/2003 – Extent of WSRP v1.1 finalized
11/1/2003 – WSRP v1.1 change control status
12/15/2003 – WSRP v1.1 approved as TC spec
2/1/2004 – WSRP v1.1 public review ends
3/1/2004 – WSRP v1.1 submitted to OASIS

 Bill: we need to have some time to deal with issues people will find when they implement the spec, especially people outside this room

 Mike: I think we can deal with that stuff in a v1.1 time frame

 Bill: We should probably look for more than 3 implementations before we put forward to OASIS; I would be comfortable with 6 companies with implementations

 Charlie: This is not what OASIS requires. OASIS requires just 3 companies using.

 Bill: I understand, but I think we owe it to ourselves to wait longer to make sure the spec is stronger

 Mike: Will you specify it explicitly with criteria for when it’s ready or give an arbitrary time limit?

 Bill: I said my criteria along with a minimum time limit before we go to OASIS standard. What do others think?

 Yossi: If we are not at standard, we will not get the “hype” that puts it on the priority list. We know that all specs have bugs; it’s not the worst thing in the world

 Sasha: I agree with Bill, we have to let the spec breathe more and have more implementations. It’s incredibly difficult to explain to both people outside this room and inside the room. It will take a long time to work out interop kinks

 Thomas: We need to walk a middle line because this is a chicken and egg problem. We should give it more than 90 days but less than a huge amount of time.

Alejandro produces an egg as an illustration

 Rich: There seem to be some implementations underway that are a bit rough, we have a good chance of getting some interop by late summer

 Mike: What is interoperating? How will we know when we get there?

 Yossi: But we don’t want to have to change the spec.

 Sasha: That’s the point of doing interop testing.

 Yossi: The truth is that implementations will interop because we will make them do so.

 Sasha: But this may affect the spec since they may have to interop outside the test.

 Mike: It would really take a year to get real commercial implementations to full fledged interop, and I’m not willing to wait for that.

 Lots more debate about this that I’m not able to take down

 Thomas: How about an extra 30 days after required period?

 Bill suggests something around July 30th or so

 RichardJ: We actually have to submit it on a 15th

 We go around the table talking about submitting on July 15th or August 15th: relatively split around the table

 Rich: Could folks who said July be “more inclusive” of folks who said August?

 Much more debate on what to do about this, eventually comes out as a vote

 DavidH: Do we know who is working on an implementation and where those project are in dev?

 Mike: Probably by (late) summer we will have some Consumers of alpha/beta quality and some very simple Producers

 DavidH: Am I a member?

 Rich: The F2F only counts as one meeting, so no.

 DavidH: Does dinner count?

 Everyone: Not so much.

 Vote for August 15 vs. July 15 for submit to OASIS

August 15: 6
July 15: 10

 Bill: This is the first time the IBM folks have all agreed on a vote!

 So final agreement:

1 Jun 2003 – v1 Public Review finishes
10 Jul 2003 – Submit v1 to OASIS as “standard”
1 Oct 2003 – Decide composition of WSRP v1.1
1 Dec 2003 – Significant draft of WSRP v1.1 content
1 Mar 2003 – WSRP v1.1 approved as TC spec
1 Apr 2003 – WSRP v1.1 public review ends
10 Apr 2004 – WSRP v1.1 submitted to OASIS
These dates are guidelines to be modified to the dates of the F2Fs, etc.

 F2F dates

General feeling that we should have a mid-September meeting to decide composition of WSRP v1.1
Debate about 3 vs. 4 days
Let’s start with 4 days and constrict if necessary
15-18 September 2003 for next F2F
Next F2F is tentatively 12-15 Jan 2004

 Back to conference calls for sub committees

Some of the subcommittees are mostly concerned with 1.0, especially Interop/Conformance, and maybe it should meet more than the others
Alan: Something like PFB shouldn’t meet that much for the next few months
Rich: Conformance and Interop might need to be split up
Mike: How often will we have the TC meeting? Weekly?
Rich: Not weekly. Perhaps biweekly half hour?
Final decision:
Tuesday
8 PT
9 PT – PFB (weekly after 7 Jul 2003)
Wed
7 PT – WSDL (biweekly starting 30 Jul 2003)
8 PT – Markup (monthly, weekly starting 10 Sept 2003)
also Coordination (biweekly starting 9 Jul 2003)
9 PT
Thursday
8 PT – TC (biweekly)
9 PT – Conformance/Interop (weekly)
List of chairs:
V1.0
Interop (Richard)
Conformance (Rich)
V1.1
Markup (Rex)
Publish/Find/Bind (Alan)
WSDL (Andre)
Interfaces(Mike)
V2.0
Coordination (Rich)
Face To Face Location Possibilities:
T.J. Watson Research Lab, Hawthorne
Downtown NYC possible?
We will decide later

Subgroup presentations – WSDL (Andre)

 Proposed Charter

Responsible for mapping WSRP operations and types (new factors?) to WSDL
Determine binding to SOAP
Should it also go to other bindings?
Evaluate our Web Service description and its impact on common Web Service Stacks
Are testing AXIS, .NET, and JAX-RPC
Not really testing others, including custom stacks and WASP
Leverage attachment mechanisms
Facilitate WS/SOAP (WS-Security) and transport level security
Possibly 2.0 thing
Investigate performance of WSRP?
Others?

 Proposed Deliverables

WSDL service desc
WSDL issue resolution recommendation
Standards coordination with things like WS-Security and WS-I.org
DavidH can help with WS-I coordination
WSRP WSDL Report (cf. 5th F2F note)
Attachment mechanisms investigation
Application level security investigation?
Andre’s 2.0 wish list:
Interoperable, standards based security
Defines consumer/producer trust relationship
Communicates user identity and roles
Digital sig, multi-hop, non-repudiation?
Secure navigational state?
Others?

 Attachment Mechanism

Why do we need this? WSRP is XML and Markup is XML, right?
What’s the problem?
Almost all HTML currently is not XML
Portlets produce Markup fragments not Documents
Different character sets between XML and the payload
Input and Output of binary Documents
Perceived performance problems of in-band sending
Current in-band support
Encode markup in as an xs:string
Encoded using XML char entities (<, etc.)
Done automatically by Web Service Stacks
Some producers can use CDATA sections
Encode “markup” as a xs:base64Binary
Size is about 1.3x the size
Done automatically by Web Service Stacks
Natural for binary docs (byte[], not String)
Future? Encode XML Markup as <any namespace= “##other”>
Requires a deserializer
Out-of-band possibilities
By reference (URLs, cf. Portlet resources)
Via http (non SOAP binding for getMarkup)
Via multi-media protocol(SMIL, RTP, DIME)
Using Various attachment mechanisms
SOAP Messages with Attachments
SOAP 1.2 Attachment Feature
WS-Attachments
Proposed Infoset Addendum to SOAP Messages with Attachments
WS-I.org profile proposals
In-band preserves XML Infoset
Keeps XML-abilities
One tool set, on charset (UTF-8!)
Canonical representation, digital signing
Multiple transports (WSDL bindings)
Tools and intermediate msg processors see data
SOAP header data as well as body
OOB may not buy a lot of performance
OOB builds on a common practice
Multi-Part MIME
SOAP with Attachments (SwA) supported by JAX-RPC
Natural for posting binary documents
Dime
DIME is a binary encapsulation protocol
Companion WS-Attachments
MS WSE 1.0
Apache Axis (support not scoped)
Championed by MS & IBM
WSRP 1.0 can use DIME at the sub-WS level
Citrix prototype uses WSE 1.0
SOAP with Attachments (SwA)
Simple
Multipart/related
MUST put SOAP envelope as first MIME part
MAY send additional MIME parts with root part
Use URIs to id parts
JAX-RPC
WSDL 1.1 has MIME extensions (Section 5)
Only for SOAP (multipart/related) in practice
Not supported by all WSDL tools (or WS stacks)
WSDL 1.2
SwA extension to WSDL may have been factored out of 1.2, unclear what happened here
WS-Attachments
Specifies Compound SOAP structures
URIs reference various parts
SOAP message + “attachments” in a DIME message
HTTP binding (application/dime)
In an MS draft of 8 May 2002 “WSDL Extensions for SOAP in DIME”
XML Infoset friendly proposals
People have problems with these since the information is outside of the message
Can convert to base64 as required
Xinclude-like mechanism could be used
These are ways of not doing attachments but rather optimizing the in-band solution
New Infoset-friendly Proposal
The “Proposed Infoset Addendum to SwA”
Aligned with XML Infoset, and backwards compatible SwA message syntax
Proposal from BEA, Microsoft, and others

 Recommendations?

Experiment with DIME, SwA?
Wait for WS-I.org (1.1 including Attachments)
Wait for WSDL extensions?
Wait for Infoset friendly SwA?
Support both in-band and out-of-band in 2.0
Add negotiation to WSRP??
Keep xs:string & xs:base64Binary for interop

Wrap up (Rich)

 We will defer the question from before lunch about honoring mode until tomorrow at 9am

ADJOURNMENT