Start at11 am
n Beginning agenda/meeting goals review
n Lots of organizational stuff today: charter, secretary, chair, etc.
n Intros:
o In Person:
§ Thomas Shaeck, IBM
§ Richard Jacob, IBM
§ Mike Freedman, Oracle
§ David Ward, Oracle UK (non-voting)
§ Andre Kramer, Citrix
§ Carsten Leue, IBM
§ Sasha Aickin, Plumtree
§ David Holladay, Microsoft (non-voting)
§ Rich Thompson, IBM
§ Nigel Ratcliffe, Factiva
§ Yossi Tamari, SAP
§ Alejandro Abdelnur
§ Bill Cox, BEA
§ Subbu, BEA
§ Alan Kropp, Vignette
o On call:
§ Atul Batra, Sun
§ Rex Brooks, Individual
§ Charlie (after lunch)
§ Jon Klein (after lunch)
n 15 out of 25 voting members is quorum
n The long dark wait for secretary (as always)
o Sasha takes notes for meeting
o Alan will do the calls
o Woohoo. The worst part is over.
New Charter (Rich)
n First involves name change (Web Services for Remote Portals à Web Services for Remote Portlets)
n Some semantic changes to deliverables in charter, less generic
n More in agreement with what we actually did in WSRP 1.0
n A few new items to deliverables
n A new 5th phase in the work schedule
o About designing advanced capabilities
n Bill expresses concern about not being able to see the whole document at once and is not comfortable with voting on a charter change without getting it out to the rest of the committee on e-mail
n We deal with technical issues (Rich can’t e-mail out, so we transfer to Yossi’s machine to e-mail out to the list)
n MikeF suggests that we should remove aim #2 (cooperation with WSIA) since WSIA will be gone
n New aim #2 (old aim #3) is about cooperation with other standards
o Alejandro raises the fact that JSR168 is not mentioned
o Bill says that we aren’t working to work together with DOM (which is mentioned), but we are working with web application environments (which is not). He doesn’t know if we should modify the list or delete.
o Bill concretely suggests that we should mention web applications and JCP JSR168
o We talk about taking Flash out of the list
o Some small debate about whether we should add JCP and/or JSR168
o Rich suggests there are two things we are saying here: we want to harmonize with existing standards and we want it to be easy to use the spec in existing web app models
o Bill\ suggests specific wording: “harmonize WSRP… with the work of the Java Community Process (e.g. JSR 168 Portlet Specification), with the work of the W3C, …”
o Sasha gives snide comment about replacing “.Net” instead of “Macromedia Flash”, folks generally agree
o Bill suggests we add WSBPEL (Web Services Business Process Execution Language)
n Statement of purpose is all right by everyone
n Now, the list of deliverables
o Rich changes the tense and verb agreement of the statement; there is some controversy
o First aim is to allow businesses to deploy Producers that can be used by Consumers
o Second aim is to allow them to deploy Consumers that can aggregate Producers
o Third and fourth aims are for future of the spec
o Third aim is allowing Consumers and Producers to cooperate in customizing user interfaces
o Fourth is to coordinate interactions between portlets that are aggregated on a page
o Fifth is publishing to registry; Rich has taken out reference to UDDI
o Sasha brings up the idea that the point of the spec is for Portals to aggregate Portlets (not Consumers to aggregate Producers). “Consumers” and “Producers” are terms that are used in the spec to reach the ends.
o Mike suggests we turn “Consumer” to “Portlet consumer”
§ We basically agree; change is made
o Rich suggests that interactions between portlets are not necessarily “on the same page”
§ Gets changed to “enable portlet consumers to coordinate interactions with portlets”
o Subbu brings up some concern about the phrase “cooperation in customizing user interface”
o Bill argues that we should take out “cooperate” in the creation of user interfaces because either the portal or portlet can do things by itself
o Mike & Rich argue that cooperation is in addition to them being able to do their own UI creation
o On to publishing portlets in registries
§ Discussion about publishing “portlets” or “portlet meta-information”
§ Agree on “portlet meta-information”
o Last point becomes “find and exploit portlet meta-information”
§ Everyone agrees that “exploit” is the best verb in the charter
n We move on to the list of things that shall be possible
o First says that portals can consume WSRP web services, using “generic proxies”
§ Several folks (Alejandro, Bill, etc. don’t understand “generic proxies”
§ Mike says it has to do with a notion of a “generic portlet proxy”
§ Carsten defends it as meaning that no portlet specific code is needed on the portal
§ Yossi says we’re making the charter too generic: we could find and replace WSRP and WSBPEL and hand it over to the BPEL folks
§ Several folks (Rich & Bill) suggest taking out “using generic proxies”
§ Carsten defends the sentence as meaning “plug and play”
§ Rich says that each portal will have its own portlet proxy, so it won’t be generic
§ Mike says this isn’t a proxy in any sense
§ Thomas says that it meant that you could write code once as a client for all portlets
§ Mike & Alejandro argue that this is so basic that we don’t need to say this, and/or it shouldn’t be in a list of “examples” of things that could be used
§ We take out “generic proxy”
o Second says you can publish local portlet through WSRP
o Third says we will work on J2EE and .NET
n Sidenote: DavidH lets us know that “.NET” is officially all caps
n Last piece: the new 5th phase of WSRP work
o Designing advanced capabilities which
§ Leverage emerging standards
· Stateful Web Services
o Bill: what is this?
o Rich: has to do with W3C working group about stateful web services (getting around HTTP cookie)
o Bill: and when will this come out?
o Rich: unclear
o Bill: I have trouble calling this an “emerging standard”
o Rich & Mike: these are examples of things that we should think about working with
o Bill wants to delete it because it may not really be an emerging standard; folks agree
o We take it out
BREAK FOR LUNCH
AFTER SOME LOVELY DUCK AND MEDIOCRE PASTA, WE RETURN TO:
· Web Services Security
· Registry, Factory, and Event Interfaces
o Bill has a problem with this list in general one, especially Factory and the Stateful Web Service which may not have standards emerging and Registry for which a standard has emerged
o We agree to take out Factory and Event
· Relevant XML vocabs
§ Enable cooperation between Consumer & Producer in generating consistent aggregated markup
· Producer changed to “Portlet”
§ Enable Consumers to discover and exploit advanced capabilities of Producers
· Changed to “Portlets”
§ Enable Consumers to discover and effect places where coordination between Portlets aggregated onto a page is helpful to End-Users.
· Debate about whether cooperation is portlet to portlet or portlet to portal to portlet
§ Enable advanced caching of markup by either the Consumer or End-User agent
· Specifically about invalidation caching, which Rich points out that we explicitly deferred to ourselves earlier on
· Bill says he doesn’t like our current caching, so he’s unhappy with adding caching ideas; wants clarification for “advanced”
· Bill: that “advanced” is a “meaningless marketing term”
· Alejandro: they’re “advanced” because we don’t have them. Go ahead and remove “advanced”.
· Bill: the very issue of conformance/compliance is often do everything (even if it’s optional) for standards organizations or government agencies, so optional isn’t really optional
· Mike: This is a much larger problem, since the spec has tons of optional things already
· Bill: Yeah, but taking an optional feature and making it “advanced” is even worse
· Mike asks if the charter is for others to understand us or us to understand ourselves
· Bill: yes
· Rex: we need to “stake out territory” for the spec
· After some more debate, Bill suggests a change from “enable invalidation caching” instead of “explore advanced caching”
· Mike: is this going to be a club that is come back to beat down someone who wants to go beyond invalidation caching?
· Bill: “Advanced” is something where we won’t know if we’ve actually achieved it
· Bill: We’re going to have turnover of staff on the committee; we need to be specific in the charter about where we’re going
· Mike: But we need leeway to go different ways
· Yossi: it’s too specific to say that we are just doing invalidation caching. We should have all kinds of caching be up for discussion in the charter.
· Mike: this is a detail and limits the growth of the spec
· Bill: we should just change the charter if we want to go in a different direction
· Mike: I don’t want to amend the charter every time; make it non-normative
· Rich: A good charter gives direction but does have holes you can drive a truck through; it needs to be broad, but it’s a balancing act
· Charlie: mentioning invalidation caching seems too specific
· Alan: but the wording right now says “additional capabilities, including”, so it’s not restrictive
§ Then we get into a discussion of “find” vs. “discover”
· Mike: “discover” is used for capabilities of the portlet, which is what we already do, whereas “find” is to find just a portlet
· We change it to “Enhance Consumers’ ability to find portlets”
§ Jumping back to caching, we change it to “Explore invalidating cached markup.”
o Should we update the times to reflect what came about?
§ Bill: are the times from the zero point of WSIA, zero point of WSRP?
· Rich: sidenote – to mesh with OASIS process, best thing to do is to merge work product (which is done) and for WSIA to quietly say it is done and disband
§ Bill: let’s make sure we specify from when these time periods start
§ Resolution: say “will take roughly an additional two years”
n Sasha moves that we accept as “clarified charter”
o Alan seconds
o Vote: 16-0-0
o Motion carries
n Sasha moves for a name change to “Web Services for Remote Portlets”
o Bill seconds
o Passes without objection
WSIA/WSRP Merger
n We have now updated charter; shall we have WSIA members join WSRP and move on together?
o Charlie: I think this makes a lot of sense. The WSIA topics of interest are now in the WSRP charter, and clearly things are going this way.
o Alejandro: I think that some of the goals of WSIA are not what we want in WSRP; coordination is an example of this. If we just talk about eventing between portlets, fine. More is problematic
o Charlie: I think the charter as it is right now really reflects this, and I don’t think we want to go further. Also, there are no additional members to add by adding WSIA
o Alejandro: I’m not concerned about people; I’m concerned that charter would have to be too wide
o Charlie: I’m not proposing widening the charter; the charter as it is is fine.
o Bill: This isn’t a meeting of WSIA, so we really can’t vote on WSIA to dissolve
o Charlie: Yeah, this is not a WSIA meeting, but I would recommend that WSIA dissolve
o Rich: This is a direction for WSRP
o Bill: Our meetings have been joint, so the WSIA people could vote on the committee shutting down
o DavidH: what are the items that were added to the charter due to WSIA?
§ Thomas: coordination of portlets is a big one
o Bill/Charlie: We’ll vote this dissolution out in WSIA over e-mail
o Charlie: The last thing is to take the assets from WSIA (especially use cases, etc.) and incorporate them into WSRP
o Bill: Note that dissolving WSIA might mean that the list archive will disappear; let’s make sure we don’t do that
New Chairperson
n Thomas will be stepping down as chairperson
n Thomas nominates Rich
o Bill seconds
n Other nominations?
o None
n Rich accepts the nomination
o Question is raised about whether he can remain technical editor
o Rich will do both, but will not be able to take on other tasks
n Thomas moves for a vote
o Vote:17-0-0
o Motion is carried; Rich is the new chair
Discussion about dinner tonight
Use Cases – Rich
n Not going to be worth our time to go through all of the use cases that version 1 covers, but we will list them
o On WSRP side, Web Service for Remote Portals, Portals Sharing Information, and Content For Portals could all be implemented (provided in the latter that there is seamless integration between Portlet and its related website
o On WSIA side, Supply Chain Aggregation, Universal Bank, & ADA Educational Studies all would work
o On WSIA side, Wireless Stock Trading is mostly there (except for disconnected portlet functionality which lies outside our scope)
n Multimedia Sports Portal (WSRP side)
o Aggregator takes disparate content source into a coherent user interface
§ Indy car example:
· Driver cam, driver stats, car stats, course layout
§ When you select a driver, you would
· Get his/her cam, his/her statistics, his/her car stats, his/her position on course
o This use case needs some sort of Consumer coordination of portlets
o Needs public runtime state to run
n Syndication of Mapping service (WSIA)
o Scenario
§ Mapping service seeks to increase control over how their maps & related controls are used on client sites that their UI improves user satisfaction
§ Move from just giving an URL to the map image to giving a full UI
§ Clients desire to modify with markers in the map
n Mortgage Calculator (WSIA)
o Producer offers a mortgage center component Consumer may easily aggregate
§ Provides useful functionality to End-users
· Needs links to Consumer data for optimal function (e.g. credit score)
§ Provides links to Producer’s web site for acquiring product info
§ Desire for Consumer to easily integrate into their own look and feel
o Needs public runtime state
o Bill raises objection to calling this “public” state
o Discussion about what this use case is about; essentially it is the Portal sending along context information (like the user’s credit score)
n Beauty Boutique (WSIA)
o Consumer is an e-Commerce web site that:
§ Provides access to a specialized provider (consmetics)
§ Producer controls branding/experience within space allocated by Consumer
§ Consumer potentially initializes product or product category for starting user navigation
§ Producer can add to Consumer’s shopping cart
§ Producer tells Consumer when user is done and should exit to larger site
§ Any combination of Consumer/Provider pages needs to be bookmarkable
o Needs public runtime state (i.e. cart, starting point)
o Needs Consumer resources
o Needs “EndUserInteraction” event
o Much debate about whether this involves leaving the portal and going directly to a portlet page
§ Essentially you need events (send the starting category, things to add to cart, and that the user is done)
§ Carsten: does state need to be transparent to Consumer?
· Rich: Needs to be transparent so that different producers can collaborate on things like shopping cart
§ Mike: The idea is that there are specific kinds of portals which have specific, concrete information (like a shopping cart)
§ Bill: This is more complex than it needs to be
§ Charlie: No, it doesn’t have any more than what we’ve been talking about
n Product Configurator (WSIA)
o Manufacturer offers a configurator for products
o Retailer wants to incorporate the configurator with:
§ Look and feel control
§ Replaced branding
§ Initial parameters
§ Add price & availability as offered by retailer
o Needs ability of Consumer to identify/replace portions of markup
o Needs public runtime state
o Needs logical events (product added to product list)
n Smart Buyer (WSIA)
o Consumer is an e-procurement app that:
§ Supports SSO to independent supplier systems
§ Controls access to products on per producder/per user basis
§ Searches for lowest cost/best avail across multiple suppliers
§ Suggests alternatives to lower total cost of requisition
§ Replaces shopping cart functionality of suppliers
§ Provides persistent requisitions independent of fulfilling supplier
o Needs either:
§ Ability to locate and replace elements (shopping cart)
§ Consumer resources
o Sasha: This seems to not involve UI markup at all and not be within our scope
§ Rich: the controlling access to products on per producer/ per user basis and replacing shopping cart are UI issues
§ Sasha: I don’t agree
o Subbu: Aren’t there other ways of doing this in existing web service standards?
§ Atul: You can build this on top of data web services, but if we have WSRP services on the supplier side, then how does the consumer use them?
o Rich: The things that have to do specifically with e-procurement are out of scope, yes.
n Financial Charting (WSIA)
o Producer has stock plotting software that allows clients to control various portions of the UI. Would like to move to a web service infrastructure that
§ Provides for client input of parameters that control the generation of the plot
§ Allows the client to customize look and feel of the resulting plot
· Add UI elements for additional symbols
· Add controls for date range, scale, etc.
o Needs standard method of identifying places where markup can be inserted
o Alejandro: Is this a notion of master portlet and slave portlets? Is it the portal adding controls or other portlets?
o Charlie: I remember it as other portlets adding controls
o Sasha: I remember opposite
o All agree that this should be done with customization parameters of the portlet
n Adaptation of Traveller’s Cheques (WSIA)
o Bank resells traveler check through syndicated app
o Bank would like to adapt choice of payment methods, and insert pages into application’s flow
o Rich proposes that this now falls within WSBPEL
o General agreement
n Rich: Now let’s go back and see what use cases we want in v2
n Yossi: Let’s decide what we want to be 1.1 and 2.0 first, and be clear about what we mean by coordination. Then look at the use cases later.
n Mike: Most of these use cases are not priorities. Let’s work on what we’ve been talking about doing with the spec and worry about these later, if ever.
n Rich: I think the first 3 describe the same needs and are useful.
n Much debate around the Mapping Service: Is this in scope any more?
o Mike: Sports portal is the only one we need; the rest are redundant and cause confusion
o Eventually, we agree that all of the important requirements are in the sports portal use case. The rest can be discarded.
n Looking back at the charter, we see that we don’t have a use case for 5b.
o We go back to find Mike’s original e-mail about sharing a consistent look and feel among different portlets
o Mike will create a use case for this
n Mike would like a use case for 5c as well
o PFB subcommittee tasked with this
Introduction (Rich)
n Going over agenda for the day
WSRP v.1.1 and v.2.0 Guidelines (Rich)
n v1.1 -- We’ve talked in the past about
o No API changes
o Some additional markup rules
o Publish/Find/Bind added
o Leverage attachment mechanisms
o Editorial “clean up” of v1
n 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?
o Rich: We’d like to keep stability of the API and incorporate what we find out through implementation
o Bill: Great.
o Rich: We want a relatively quick cycle to go through small changes
o 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.
o Thomas: Are there really ways that PFB would change the API?
o Andre: It might add a port type.
o Rich: These are not hard and fast rules; this “don’t change the API” is a guideline. If we have to tweak, we can.
o Thomas: Cross-compatibility of 1.0 and 1.1 is critical (along with APIs).
o Carsten: Will we have backward and forward compatibility?
o Rich: You always have to support the basic bindings.
n V2.0 ideas
o Additional means to customize markup
§ Consumer resources?
o Means to coordinate interactions among portlets
§ Transparent transient state (request/session level)
o Leverage additional standards where appropriate
o Explore invalidation caching (some folks are for, some are against)
o Miscellaneous deferred items
o Others?
n Alan: Are there going to be any caching mods for 1.1?
o Rich: I think it’s hard to do in terms of time and without changing it too much
Deferred Items to Assign (Rich)
n Rich looked through the notes and found deferred items; let’s look at the list and decide:
o 1.1 vs. 2.0
o sub-committee to work on it
n Items:
o Markup rules for other markups (Xforms, cHTML, VoiceXML)
§ For v1.1
§ Markup SubCommittee
o Publish/Find/Bind
§ For v1.1
§ PFB SubCom
o 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
o Exploiting attachments
§ For 1.1
§ WSDL SC
o Exploiting message level security (WS-Security)
§ For 2.0
§ Interfaces SC
o Align with emerging standards
§ Remove Registration portType in favor of other standardized portType (Grid?)
§ For v2.0
§ Interfaces SC
o Coordination
§ Cross-producer coordination (eventing)
§ Session-level Properties
§ For v2.0
§ Coordination SC
o Enhanced Caching
§ Specifically invalidation caching
§ For v2.0
§ Interfaces SC
o Customization
§ Support for Consumer specified controls and control sets
§ Session-level Properties
§ For v2.0
§ Interfaces SC
o 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
o Fields that were deferred
§ PropertyDescription.propertyUsage
§ IsSecure
§ RewriteRedirectURL
§ ServiceDesc.version
§ A bunch more
§ For v2.0
§ Interfaces SC
o 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)
n 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
o When the mode changes, performInteraction is not called so nav state can’t change
n 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?
o 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
o 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.
o Bill: Let’s get the problem written down clearly before we jump into solutions.
n Rich: Alternative way to get to nav State and mode be out of sync
o Activated URL requests mode change and provide a new navState
o Consumer decides to not honor mode change request, invokes portlet with different mode and new navState
n Thomas: This is not a problem because navState and mode are orthogonal (mostly).
n 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?
o Rich: currently the spec only goes forward, no notion of a stack
o Andre: I think this causes a problem of not having a history, and not knowing when to clear this history.
n Rich: Problem arises if the portlet developer presumes a correlation between mode and navState
o Mike: and we’ve designed that each portlet has no beginning navState in any mode, which is important to note
n Now, we need to figure out if this is a problem or not.
n Bill: If this makes a major training problem for current developers, then this will be a major problem
n Sasha: Gives e-mail portlet example
n Rich: This comes from our general belief that navState corresponds to URL in a normal web app. Translates over directly for stateless portlets
n Mike: This is a problem not of navStates or sessions; it’s a problem of modes.
n Rich: So web app developers won’t be used to this, but portlet developers will be
n Mike: In our portal, portlet devs do get to always change mode and assume it works; they don’t have to worry about it
n Andre: You can set session variables on getMarkup
n Mike: If you do things in navState, you have to “pre-anticipate” and carry things through in all URLs
n DavidW: My problem is that the Consumer can change the navState but not the mode. That seems wrong
n 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
n Rich focuses us back on the following points:
o 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
o Stateless portlet is more difficult than stateful portlet.
n 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.
o Rich: We have primer work and the conformance statement.
o Mike: Also, the question of decoration involved.
LUNCH
Calendar for Teleconferences (Rich)
n We discuss times for calls
o Tuesday
§ 8 PT
§ 9 PT – PFB (weekly)
o Wed
§ 7 PT – WSDL
§ 8 PT – Markup
§ 9 PT
o Thursday
§ 8 PT – TC
§ 9 PT – Conformance/Interop
Timeline for WSRP
n Proposal
o 6/1/2003 WSRP v1 public review finishes
o ??? – submit v1 to OASIS as standard
o 10/1/2003 – Extent of WSRP v1.1 finalized
o 11/1/2003 – WSRP v1.1 change control status
o 12/15/2003 – WSRP v1.1 approved as TC spec
o 2/1/2004 – WSRP v1.1 public review ends
o 3/1/2004 – WSRP v1.1 submitted to OASIS
n Bill: we need to have some time to deal with issues people will find when they implement the spec, especially people outside this room
n Mike: I think we can deal with that stuff in a v1.1 time frame
n 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
n Charlie: This is not what OASIS requires. OASIS requires just 3 companies using.
n Bill: I understand, but I think we owe it to ourselves to wait longer to make sure the spec is stronger
n Mike: Will you specify it explicitly with criteria for when it’s ready or give an arbitrary time limit?
n Bill: I said my criteria along with a minimum time limit before we go to OASIS standard. What do others think?
n 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
n 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
n 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.
o Alejandro produces an egg as an illustration
n 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
n Mike: What is interoperating? How will we know when we get there?
n Yossi: But we don’t want to have to change the spec.
n Sasha: That’s the point of doing interop testing.
n Yossi: The truth is that implementations will interop because we will make them do so.
n Sasha: But this may affect the spec since they may have to interop outside the test.
n 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.
n Lots more debate about this that I’m not able to take down
n Thomas: How about an extra 30 days after required period?
n Bill suggests something around July 30th or so
n RichardJ: We actually have to submit it on a 15th
n We go around the table talking about submitting on July 15th or August 15th: relatively split around the table
n Rich: Could folks who said July be “more inclusive” of folks who said August?
n Much more debate on what to do about this, eventually comes out as a vote
n DavidH: Do we know who is working on an implementation and where those project are in dev?
n Mike: Probably by (late) summer we will have some Consumers of alpha/beta quality and some very simple Producers
n DavidH: Am I a member?
n Rich: The F2F only counts as one meeting, so no.
n DavidH: Does dinner count?
n Everyone: Not so much.
n Vote for August 15 vs. July 15 for submit to OASIS
o August 15: 6
o July 15: 10
n Bill: This is the first time the IBM folks have all agreed on a vote!
n So final agreement:
o 1 Jun 2003 – v1 Public Review finishes
o 10 Jul 2003 – Submit v1 to OASIS as “standard”
o 1 Oct 2003 – Decide composition of WSRP v1.1
o 1 Dec 2003 – Significant draft of WSRP v1.1 content
o 1 Mar 2003 – WSRP v1.1 approved as TC spec
o 1 Apr 2003 – WSRP v1.1 public review ends
o 10 Apr 2004 – WSRP v1.1 submitted to OASIS
o These dates are guidelines to be modified to the dates of the F2Fs, etc.
n F2F dates
o General feeling that we should have a mid-September meeting to decide composition of WSRP v1.1
o Debate about 3 vs. 4 days
§ Let’s start with 4 days and constrict if necessary
o 15-18 September 2003 for next F2F
o Next F2F is tentatively 12-15 Jan 2004
n Back to conference calls for sub committees
o Some of the subcommittees are mostly concerned with 1.0, especially Interop/Conformance, and maybe it should meet more than the others
o Alan: Something like PFB shouldn’t meet that much for the next few months
o Rich: Conformance and Interop might need to be split up
o Mike: How often will we have the TC meeting? Weekly?
§ Rich: Not weekly. Perhaps biweekly half hour?
o 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)
o also Coordination (biweekly starting 9 Jul 2003)
· 9 PT
§ Thursday
· 8 PT – TC (biweekly)
· 9 PT – Conformance/Interop (weekly)
o 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)
o Face To Face Location Possibilities:
§ T.J. Watson Research Lab, Hawthorne
§ Downtown NYC possible?
§ We will decide later
Subgroup presentations – WSDL (Andre)
n Proposed Charter
o Responsible for mapping WSRP operations and types (new factors?) to WSDL
o Determine binding to SOAP
§ Should it also go to other bindings?
o 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
o Leverage attachment mechanisms
o Facilitate WS/SOAP (WS-Security) and transport level security
§ Possibly 2.0 thing
o Investigate performance of WSRP?
o Others?
n Proposed Deliverables
o WSDL service desc
o WSDL issue resolution recommendation
o Standards coordination with things like WS-Security and WS-I.org
§ DavidH can help with WS-I coordination
o WSRP WSDL Report (cf. 5th F2F note)
o Attachment mechanisms investigation
o Application level security investigation?
o 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?
o Others?
n Attachment Mechanism
o Why do we need this? WSRP is XML and Markup is XML, right?
o 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
o 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
o 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
o 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
o OOB builds on a common practice
§ Multi-Part MIME
§ SOAP with Attachments (SwA) supported by JAX-RPC
§ Natural for posting binary documents
o 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
o 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
o 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”
o 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
o 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
n Recommendations?
o Experiment with DIME, SwA?
o Wait for WS-I.org (1.1 including Attachments)
o Wait for WSDL extensions?
o Wait for Infoset friendly SwA?
o Support both in-band and out-of-band in 2.0
o Add negotiation to WSRP??
o Keep xs:string & xs:base64Binary for interop
Wrap up (Rich)
n We will defer the question from before lunch about honoring mode until tomorrow at 9am
ADJOURNMENT
THE SECRETARY ARRIVES HALF AN HOUR LATE, IN THE MIDDLE OF:
Discussion on NavState and Mode:
n Mike suggests that:
o Portlets can assume that the initial state is null and that the mode is view
o If not, then the Portal will send an performBlockingInteraction action
o And for any action the Portal sends that makes the Portlet go into a different mode, a performBlockingInteraction must be performed
n Yossi has an objection concerning portlets that start in edit mode
n Carsten argues that there is no relationship between navState and mode
n Mike: If we want to say that for stateless portlets, navState can’t change when mode changes, then we need to find a way to make the same restriction for stateful portlets
o Carsten: getMarkup is readonly, and mode can change in getMarkup. Doesn’t this make mode change readonly
o Mike: the spec allows mode change to come in as actions or not
n Carsten: this is because of a misconception by developers of stateful portlets; they shouldn’t be writing to the session when changing mode
o Mike: But this is a common thing for developers
n Carsten: we should give guidelines for developers
o Thomas: maybe we should enforce this through JSR 168
o Carsten: doesn’t JSR 168 say getMarkup is read-only?
o Thomas: we shouldn’t allow this in WSRP-JSR 168 bridges
o Various other folks (Mike, Alejandro) think that web app developers will go “ballistic” if we don’t let them access the session and that we have to allow session access
n Another proposal is to leave the spec as is
n Andre: Yet another proposal is to create a new operation that deals with decoration mode changes. Wouldn’t overload this method (performBlockingInteraction) even further.
n We also look at whether Consumer honoring Producer’s mode change request should be a MUST or a SHOULD
o Sasha: Let’s make it a MUST. In the cases where the Consumer doesn’t want to honor it, it shouldn’t call across to the Producer
o Rich: But what about when a mode is returned from performBlockingInteraction? This will still be broken.
o Sasha: This is a second problem. Making it a MUST would fix the first but not the second.
n Alan: Let’s take this discussion to e-mail.
n Rich: Can we agree on this wording:
o CSO 66 “…MUST respect this request to change the mode outside of exceptional circumstances (e.g. access control restrictions), but since the Portlet cannot depend on that choice it MUST NOT encode this new mode into any of its stateful settings.”
o Sasha: the second half is confusing; let’s change to “MUST NOT depend on such a request”
o Mike: Should the second half be “SHOULD NOT”?
§ Others: or lower case “must not”
o
n Rich: Should we do this for window state too?
o General belief is no.
o CSO 65 “…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…”
n Alejandro: Will this conformance statement affect both changes on performBlockingInteraction and URLs with mode requests?
o Rich: yes
n Rich: Back to the question of whether portal-initiated mode changes happen only through the invocations of performBlockingInteraction and initial state is always “view”/“normal”?
o Carsten objects to performBI being called for a mode change because this doesn’t change portlet state
o Straw poll: 5 for performBI being called; 7 against performBI being called; 3 abtains
§ We transfer this to be a vote, no one objects
Charters – Interoperability SC (RichardJ)
n Purpose is to test the interoperability of the spec and see what problems will come about
o Allows participants to check their implementations against others
o Allows participants to coordinate and organize interop
o Start initial testing of protocol flow between implementations
o Allow participants to validate/discuss implementations
n Deliverables
o Publish access points of producer implementations willing to participate
§ Right now have IBM consumer and a few others in the pipe
· Oracle, Vignette
§ Vignette is working on a producer (TBA, possibly in May)
o Report interop results
§ Matrix of current status per participant
§ Doc issues
o Doc interop tests
Charters – Conformance (Rich)
n Purpose is to extract conformance statements that can be used to test conformance
n Identify testing frameworks
n Purpose
o Identify use profiles with the applicable conformance statements
o Get assertions out of conformance statements
o Using testing frameworks (right now from UDDI and WS-I)
o Develop tests cases for testing frameworks
n Deliverables
o Sets of conformance assertions that reflect WSRP v1 spec
o If testing framework is chosen, a suite of test cases that reflect conformance specs
Charters – Coordination (Rich)
n Purpose
o Eplore expanding property concept to include transient state
o Expand framework for handling user interactions within WSRP protocol
o Define starter set of events and message formats
BREAK
Charters – Publish/Find/Bind (PFB) (Alan)
n Tasked with identifying requirements and recommending specs for portlet service publication and discovery
n Primary focus on UDDI 2.0 or later
n Might consider ebXML, depending on interest
n Purpose
o Describe how to publish to UDDI 2.0
o Describe PFB best practices
o Track registry standards
n Deliverables
o Guidance for publishing to UDDI 2.0
o tModels or other artifacts to be registered with uddi.org
o Primer to include common UDDI PFB scenarios
n Have gotten an expert from the UDDI TC to help out
Charters – Markup (Rex)
n Purpose
o Identify and recommend best practices for Markup types, markup interfaces fragment rules, and caching
o Identify markup specs and proprietary formats to consider for WSRP
o Develop recommendations for defining templates for all such markup types, MIME types, markup fragments, and best practices for such
o Identify and recommend liaisons to other standards groups
n Will have monthly meetings and invite experts to help out about particular markup types like VXML and WML
n Alan: Will we revisit CSS?
o Rex: Yes, it’s part of the plan
o Rich: make sure to get feedback from your company’s UI people
n Some discussion about revisiting cHTML as well
n DavidW has questions about escaping characters in mobile markup
o What happens with ampersands in consumer rewrite tokens in an XML compliant markup type like WML? Are they encoded or not?
o We will address this later on.
Wrap-Up of main meeting (Rich)
n We’ll revisit the Interfaces charter on the e-mail list
n Breakouts will happen this afternoon, but they will be sparse since many folks are leaving early
n Discussion of allowing “non-voting members” or “observers”
n Conf. Call
o Next week will be Conformance/Interop for two hours
o Next TC call will be 29 May
n Bill moves to adjourn
o Alan seconds
o No objections