|
|
William Cox |
BEA |
|
|
Graeme Riddell |
Bowstreet |
|
|
Srinivas Vadhri |
Commerce One |
|
Y |
Monica Martin |
Drake Certivo |
|
Y |
Alan Kropp |
Epicentric (chair) |
|
Y |
Charles Wiecha |
IBM |
|
Y |
Rich Thompson |
IBM |
|
Y |
Carsten Leue |
IBM |
|
|
Thomas Schaeck |
IBM |
|
Y |
Rex Brooks |
Individual |
|
Y |
Joe Rudnicki |
U.S. Navy |
|
Y |
Mike Freedman |
Oracle |
|
|
Stefan Beck |
SAP |
|
Y |
Jeffrey C. Broberg |
Silverstream |
|
|
Suresh Damodaran |
Sterling Commerce |
|
|
Eilon Reshef |
WebCollage |
|
Y |
Gil Tayar |
WebCollage |
|
|
Steve Pruett |
Silverstream |
|
|
Mike Hillerman |
Peoplesoft |
|
|
Aditi Karandikar |
France Telecom |
|
Y |
Ravi Konuru |
IBM |
|
|
Howard Melman |
Silverstream |
|
|
Angel Diaz |
IBM |
|
Y |
Alejandro Abdelnur |
Sun |
|
|
Eric van Lyndegraf |
Kinzan |
|
|
Yossi Tamari |
SAP |
|
Y |
Tim Jones |
Crossweave |
|
Y |
Bruce Lucas |
IBM |
1. Proposal for an XFORMS-based property description schema. Attached Charlie's email of 8/14 for details.
2. Continue discussion around entities we started last week, in terms of typical portal use case. This could also impact further discussions later in the week regarding the model.
Charlie walked everyone through the proposal. The main points were to separate property meta-data (the schema) from property representation (the instance), and to make the case for an XFORMS representation for the property instance (potentially netting us a hierarchical property model).
Some debate ensued about the merits of an XFORMS property representation in the protocol, as compared to the simpler flat Property model that’s presently in the protocol.
There seemed to be agreement that mixing meta-data and instance values in the same description, as is presently in the spec, is not a good thing, they should be separate.
Charlie is looking for volunteers from the WSRP side to help continue to flesh out the proposal, perhaps recasting the XFORMS approach as an advanced capability to support richer property meta-data as part of an extension path.
We revisited the entity discussion from last week.
The pure entity-less approach may be somewhat extreme, because the Producer still needs a mechanism to expose service “types”.
Also, the purely Producer-side entity models were more or less rejected at the face-to-face in June, in recognition that different consumers would have such different ways of modeling their entities, which no Producer-side model could account for all of the nuances.
So, it appears we’re moving closer to a model in that Consumers maintain their own internal entity state, opaquely and as complex as they desire, and transmit “snapshots” of the state to the Producer to facilitate the type of interaction that’s required.