[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [wsrp] Agenda for tomorrow's joint interface telecon
Some comments to the agenda: 1,1A: I believe that URL rewriting and namespace encoding should be a separate issue from a generalized adaptation mechanism. Maybe we do not need the notion of a generalized adaptation in WSRP but we definitely need URL rewriting and namespace encoding. 3. From my point of view the question CSS classes is more a detail of the protocoll than of the joint interfaces. Maybe we could defer it to the sub group that deals with fragments. Best regards Carsten Leue ------- Dr. Carsten Leue Dept.8288, IBM Laboratory Böblingen , Germany Tel.: +49-7031-16-4603, Fax: +49-7031-16-4401 |---------+----------------------------> | | Alan Kropp | | | <akropp@epicentri| | | c.com> | | | | | | 04/02/2002 04:14 | | | AM | | | Please respond to| | | Alan Kropp | | | | |---------+----------------------------> >-------------------------------------------------------------------------------------------------------------------------------------| | | | To: "'wsrp@lists.oasis-open.org'" <wsrp@lists.oasis-open.org>, "'wsia@lists.oasis-open.org'" <wsia@lists.oasis-open.org>| | cc: | | Subject: [wsrp] Agenda for tomorrow's joint interface telecon | | | | | >-------------------------------------------------------------------------------------------------------------------------------------| I've enclosed (for those who haven't seen them before) the latest working version of the WSIA Embedded use case, and set of UI abstractions that we discussed last week. This should be a good starting point for fleshing out the characteristics of the joint interface. We may wish to limit our initial discussions to the Embedded case as we're ramping up, before expanding the discussions to consider elements of the Customized case. Here's a rough outline of the work this group should focus on, additions and suggestions are of course welcome: 0. Embedded service/portlet lifecycle. Need to consider stateful(less)ness, session management, etc. What should be the lifecycle characteristics of an Embedded service, and more specifically, the lifecycle characteristics of the portal/portlet or container/portlet interaction? 1. Service adaptation mechanism. We need to determine if this is property-driven, parameter-driven, or both. In Friday's telecon, there was discussion around considering the parameter-driven mechanism for generic adaptations, while relying on properties to do producer-specific adaptation. This may also form the line of demarcation between the Embedded and Customized use cases. 1A. As a special case of service adaptation, how is URL rewriting to be handled? By the provider, the consumer, or both? URL "rewriter" specified by property, also need a convention to specify tokens for rewriting in the producer response. 2. Default set of generic properties. See section 7 in the Embedded document for the working set we've come up with so far. 3. Default set of common look and feel abstractions. This is the other attached document, a work-in-progress that lists the common abstractions (e.g. CSS classes) that group members have been working with in their own products. This list will need to be normalized once there are enough submissions. Question: is this set shared up the hierarchy of WSIA use cases? Talk to you tomorrow, 9am PST. Alan <<WSIA Embedded Use Case.DOC>> <<CSS classes_modified.doc>> #### WSIA Embedded Use Case.DOC has been removed from this note on April 02 2002 by Carsten Leue #### CSS classes_modified.doc has been removed from this note on April 02 2002 by Carsten Leue
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC