OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsia message

[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,

Clean, simple, and extensible.

-----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?


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...


-----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:

                      07/15/2002 12:47         Subject:  RE:
[wsia][wsrp-interfaces] Refactoring the data objects   



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


-----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