[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [wsia][wsrp-interfaces] Producing a joint spec?
My take on all this is to use Properties as the mechanism for passing _all_ our data. Instead of creating Contexts - structures of fields, we can define all data to be passed back and forth as provider. So, we will have a UserAgent property and a SessionGroupID property, etc. and the grouping will be done by assigning a "Category" to the property in the schema. So, the UserAgent property is of the "Request" Category, and the ConsumerHandle is in the...umm..."Consumer" catgeory. We will kill three birds in one shot - we will have properties to WSIA's delight, we will organize the fields in a more extensible manner, and we will have built our extensibility mechanism. Now performAction looks like (markupParams, properties, markup?) = performAction(markupParams, properties). Clean, simple, and extensible. Gil -----Original Message----- From: Tamari, Yossi [mailto:yossi.tamari@sap.com] Sent: Tuesday, July 16, 2002 15:52 To: wsia@lists.oasis-open.org; wsrp-interfaces@lists.oasis-open.org Subject: RE: [wsia][wsrp-interfaces] Producing a joint spec? Hi, Regarding properties, if we use this as an extension mechanism to pass profile info, than why is it returned by performInteraction and not passed to getMarkup, where it's really needed? What I'm trying to say is that I agree with the need for A/V list extension mechanism as discussed, and if WSIA wants to use this as part of its interface even though it has to semantics in the joint interface, that's fine. But from my point of view we need to look at this from the point of view of which extension mechanisms are we adding in what functions (in and out), rather than adding it to basically just one function. As for the "WSIA concepts in the WSRP standard" issue: I know this is the joint interface. from my point of view it means that it should not have any WSIA or WSRP specific semantics in it. It is the base interface that is shared by both. I am sure that if you were designing some Java class for your own application you would take my approach... Yossi. -----Original Message----- From: Rich Thompson [mailto:richt2@us.ibm.com] Sent: Monday, July 15, 2002 9:04 PM To: wsia@lists.oasis-open.org; wsrp-interfaces@lists.oasis-open.org Subject: [wsia][wsrp-interfaces] Producing a joint spec? Yossi refers to WSIA concepts in the WSRP standard. As a discussion point, I would generalize this to say that the current document says it is a joint spec .... is there a preference to split into 2 specs? On a conceptual level, properties was the one I have heard identified as a WSIA concept. It has also been proposed as a means for a flexible definition of the members of the user profile that an entity wishes to use and whether or not Producer URL writing is the entity's preferred scenario. Each of these (& others as we move forward) would require inventing other means of transferring the information if properties are removed from the interface. "Tamari, Yossi" <yossi.tamari@sap To: wsia@lists.oasis-open.org, .com> wsrp-interfaces@lists.oasis-open.org cc: 07/15/2002 12:47 Subject: RE: [wsia][wsrp-interfaces] Refactoring the data objects PM See my comments marked with [YT]. (Most of them are in appendix A, since it seems appendix a is the real definition of the spec, which I think is wrong, and is a result of what Rich mentioned below about the obscurity of the interface.) The endless debate about putting WSIA concepts in the WSRP standard is still there... Yossi. -----Original Message----- From: Rich Thompson [mailto:richt2@us.ibm.com] Sent: Friday, July 12, 2002 9:09 PM To: wsia@lists.oasis-open.org; wsrp-interfaces@lists.oasis-open.org Subject: [wsia][wsrp-interfaces] Refactoring the data objects As requested in Tuesday's Joint interfaces call, I have reworked the draft spec in an effort to factor the data items into the scopes presented at the June F2F. Personally I think this obscures too much and that some of the data items should move up to first class parameters in the interface. Hopefully this version can provide a reasonable basis for a discussion of which items should be promoted either for clarity or as part of supporting any factoring of the operations. Technical note: In order to make this readable but yet leave an indication of what was modified, I accepted the changes and then appended a space on the end of changed lines so that a change bar will appear on the left. So much changed in Appendix A that it all should be considered modified. (See attached file: WSIA - WSRP Interface Specification.doc) #### WSIA - WSRP Interface Specification1.doc has been removed from this note on July 15 2002 by Rich Thompson ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl> ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC