[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [wsia][wsrp-interfaces] Producing a joint spec?
I know, and I agree. But our xContext structures already obscure most of
them, and the important ones we want to put as arguments to the API
(markupParams, entityHandle or others) I would _not_ put as properties.
In essence, the XML generated by the xContext type of API and the properties
type of API is the same:
<propertyValues>
<UserAgent>...</UserAgent>
<CharacterSet>...</CharacterSet>
...
</propertyValues>
vs.
<requestContext>
<UserAgent>...</UserAgent>
<CharacterSet>...</CharacterSet>
...
</requestContext>
The difference is only in semantics. In the "pass-data-as-properties" now
have only one mechanism for passing all data - properties, instead of two -
Contexts and properties. This will make life easier for Development tools
which will only have to show a property sheet.
But your concern is a valid one. To counter it I repeat that, as discussed
elesewhere, not everything should be properties. The _basic_ information
that governs the semantics of the operatio between Prod. and Cons. should
not be properties (e.g. entityHandle, markupParams, clientData...). This
makes the semantics of the operations even clearer than today.
Gil
-----Original Message-----
From: Rich Thompson [mailto:richt2@us.ibm.com]
Sent: Tue, July 16, 2002 23:28
To: wsia@lists.oasis-open.org; wsrp-interfaces@lists.oasis-open.org
Subject: RE: [wsia][wsrp-interfaces] Producing a joint spec?
While this is appears clean, simple & extensible, it is roughly equal to:
response = doit (whatToDo, whatToDoItWith);
While such an API allows the execution of anything, it move all issues of
typing parameters up to the application level. It also tends to obscure
semantics whose intent can often be conveyed through well chosen operation
and parameter names.
Gil Tayar
<Gil.Tayar@webcol To:
wsia@lists.oasis-open.org,
lage.com>
wsrp-interfaces@lists.oasis-open.org
cc:
07/16/2002 04:01 Subject: RE:
[wsia][wsrp-interfaces] Producing a joint spec?
PM
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>
----------------------------------------------------------------
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