Attendance
|
|
William Cox |
BEA |
|
|
Graeme Riddell |
Bowstreet |
|
|
Greg Giles |
Cisco |
|
Y |
Srinivas Vadhri |
Commerce One |
|
Y |
Kirk |
Computer Associates |
|
|
Sean Fitts |
Crossweave |
|
Y |
Timothy N. Jones |
Crossweave |
|
|
Peter Quintas |
Divine |
|
|
Robert Serr |
Divine |
|
|
Sandra Swearingen |
DoD |
|
|
Monica Martin |
Drake Certivo |
|
Y |
Alan Kropp |
Epicentric |
|
|
Patel Ashish |
|
|
|
Aditi Karandikar |
|
|
Y |
Royston Sellman |
HP |
|
|
Dan Bongard |
Kinzan |
|
Y |
Eric van Lyndegraf |
Kinzan |
|
Y |
Charles Wiecha |
IBM (chair) |
|
|
Dan Gisolfi |
IBM |
|
Y |
|
IBM |
|
Y |
Rich Thompson |
IBM |
|
Y |
Shankar Ramaswamy |
IBM |
|
|
T.V. Raman |
IBM |
|
Y |
Rex Brooks |
individual |
|
|
John Kneiling |
individual |
|
|
Kevin Brinkley |
Intel |
|
Y |
Joe Rudnicki |
Navy |
|
|
Michael Mahan |
Nokia |
|
Y |
Mike Chapman |
Oracle |
|
Y |
Terry Cline |
Peregrine Systems |
|
|
Sasha Aicken |
Plumtree |
|
Y |
Stefan Beck |
SAP |
|
Y |
Chris Braun |
Silverstream |
|
|
Howard Melman |
Silverstream |
|
|
Jeffrey C. Broberg |
Silverstream |
|
|
Suresh Damodaran |
Sterling Commerce |
|
Y |
Eilon Reshef |
WebCollage |
|
|
Gil Tayar |
WebCollage |
Meeting convened at
1. ÊIt was announced that Rich Thompson would be taking minutes for the face to face meeting in Graemeâs absence, though Graeme will continue as the secretary for the TC.
2. Rex Brooks has agreed to take over the role of web master. He will explore the OASIS TC member-session facility, in particular can it provide collaborative support for teleconferences.
3. Discussion of the rework of the joint specification over the past 3 days. WSRP participants objected to the complexity as presented on Monday. The key required features were enumerated and the complexity rebuilt bottom up to a level that will be taken to modify the current draft. Commentary over a need for a better term than ãentityä. Also noted that any portal vendors are more focused on the view part of the interaction. Interaction with the model is often limited to design time. There is a WSRP desire to enable cross portlet collaboration · key question is whether this wants to be a generic event mechanism or a Consumer mediated mechanism as envisioned by WSIA.
4. Should the produced ãjointä spec be given a distinct name rather than caring the names of the two TCs. Possible suggestions include WS-Interaction and WS-Presentation.
5. Need to look at how things move forward both jointly and to handle unique requirements.
a. Technical: To be explored by WSIA Interfaces subgroup
b. Marketing:
WSIA volunteers are Shankar,
6. Eilon commented that the customization subgroup worked by first working through more detailed scenarios used to drive extracting requirements for use in evaluating concrete proposals.
7. Tim Jones presented ãWSIA Customizations Scenariosä
a. Memory Configurator: SKU display
i. Associating sellerâs SKU to the manufacturerâs part number.
1. Do both want to be displayed?
2. Who does the mapping, reseller or manufacturer?
ii. Part availability
1. Does the user even see unavailable parts? Visible but indicated as backordered? Only indicated by a fault when ordering?
2. Who does the availability checking, reseller or manufacturer?
iii. Reseller wants to place a ãAdd To cartä button on the configurator pages.
1. Does the configurator return the reseller SKU or manufacturer part number?
2. How to know when the configurator is done?
3. How does the data get returned?
4. What about data more complex than a single string?
b. Health Insurance Enrollment
i. Since employer has personnel info for the employee, can it initialize the personal data? Could it specify whether the employee views this data or whether the first entry screens are skipped?
1. Choices include:
a. Consumer sends data to the Producer
b. Consumer adjust markup from Producer transparently
c. Producer receives and stores employee data
d. User has to enter their data every time
ii. Employer offers a subset of the available plans, possibly varying by employee
c. Multimedia Sports Portal
i. Producer streamed video feed (eg from helmet or dashboard cam)
ii. Consumer wants to wrap this with a GUI providing driver info, offers ability to switch drivers, etc.
1. Could require user to select both driver and video feed.
2. Could cause the selection of a different driver to automatically switch the video feed shown.
a. This could happen both through interaction with the Consumer supplied GUI OR through interacting with the video feed to select a different feed from the Producer that cooresponds to a different driver.
d. Model Instance Customizations => prefilling Producer data
i. Interaction around the Producerâs model elements
1. If delegated to the Consumer, this may require metadata indicating what the insertion points are available / valid.
e. Model Instance Customizations => Returning data to the Consumer
i. Done only at compeletion?
ii. Data return at each interaction cycle?
f. Model Type and Validation Customizaitons
i. Handshaking required around schema of the property set
1. Example: Producer allows any month, Consumer wants to restrict to Jan ö March.
a. Can Consumer upload the additional constraint to the Producer?
b. Does the Consumer get informed of each property change and does the additional validation itself?
2. Example: Consumer adds relational fields constraint (eg. loan rate is 2% above prime, rather than variable)
a. Can the constraint be uploaded to the Producerä
b. Does the Consumer get property changes and forces the rate it requires?
c. May overlap with other rule interchange standard efforts
3. Example: Consumer wants to augment the types provided by the Producer (eg. Producer does not have a color subfield for the offered clothing, but Consumer wants to supply this type of information)
a. Could start with a broad type and allow Consumer to narrow the type?
b. Define opaque set of enumerable values and delegate validation to Consumer?
g. View Customizations
i. Add/delete elements, set labels
1. Could Consumer set Producer preferences so desired output is generated?
2. Producer could delegate changing the view to the Consumer by publishing metadata describing how view may be modified.
3. Consumer sets markup bindings to the Consumer/Producer data.
h. Shankar: How many of these customization cases may be done in a ãpiggy-backä fashion on the current joint API design? Ie. without the need for an event mechanism. We should also note that this is not likely an area where only one way of accomplishing an end will be the ultimate answer.
i. Functional patterns [target version]
i.
1. Initialization [1.0]
2. Incremental through interaction (transparency of property values) [1.0]
3. Termination [not 1.0]
ii. Interaction automation (Consumer initiated performInteraction) [out of band]
iii. Model augmentation (Type modification)
1. via properties [1.0]
2. defined content model for constraints [not 1.0]
3. First class support [not 1.0]
iv. Well known properties [not in protocol => not 1.0]
1. Std property names [1.5]
2. Std property types [1.5]
3. Property best practices [1.5]
v. View alteration
1. Data driven changes [1.0]
2. Consumer supplied markup [not 1.0]
vi. Producer callbacks (eg private protocol) [not 1.0 ö dependent on events?]
8. Eilon: Can we use the RequestContext structure to carry many of the concerns we have to enabling future functionality?
9. Eilon: Presented Customization Requirements
a. R401 ö 1.0
b. R402 ö 1.0
c. R403 + R404 ö transparency of properties ö 1.0
d. R405 ö 1.0
e. R406 ö 1.0
f. R407 ö merged into R403/R404
g. R408 ö scratched
h. R409 ö edited for 1.0 vs future
i. R410 ö 1.0
j. R411 ö edited for 1.0
k. R416 ö 1.0
l. R415, 417, 418, 420 ö deleted
m. R419 ö edited for 1.0
10. Charlie noted that the requirements talk about sending data to a Producer where the current concept of an entity applies. Eilon: This may be adding ãin the context of an entity/sessionä.
11. Eilon: We havenât truly justified the need for a first class property model yet.
12. Shankar: The property description must declare the scope (maximum?) for each of the properties.
13. Shankar: Should the description of the properties be an XML document which is required to conform to a property description schema that WSIA publishes?
14. API from Wednesday was revisited relative to how the property concepts should overlay it. Particular points of the discussion decided that markupParams constituted an opaque view of the entire state of an entity while properties are a view on the transparent portion of that state. The initial character of overlay of properties on the API should have the property arrays being passed to the Producer being those properties the Consumer wishes to set while the returned property array represents the full set of properties. Optimizations may include a Consumer registration indicating that it has no interest in receiving the set of properties back from the Producer. It was left as an open question as to whether property arrays overlay many other operations or just appear in setProperties/getProperties operations.
Meeting adjourned at