wsrp message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [wsrp] ExtensionDescription
- From: Rich Thompson <richt2@us.ibm.com>
- To: wsrp <wsrp@lists.oasis-open.org>
- Date: Thu, 25 Aug 2005 09:03:43 -0400
comments inline in
this color
Rich
Subbu Allamaraju <subbu@bea.com>
08/25/05 08:35 AM
|
To
| wsrp <wsrp@lists.oasis-open.org>
|
cc
|
|
Subject
| Re: [wsrp] ExtensionDescription |
|
In your example below, protocol extensions are treated
the same as open
content models used within the protocol, and this has been my concern.
RT> If you think there is an error is
how the table describes who defines what, please point it out as I think
the distinctions it makes in this area are correct and similarities obvious
(I see some handler along the way destroyed the table layout in the copy
below. Let me know if it didn't appear in the original email as a table
and I will post it as a document instead.).
When a portlet/producer defines a StormWarning event, it is using the
open content model specified in the protocol. The protocol still
specifies what an event is and how it SHOULD/MUST be treated. Whatever
data a producer or a consumer carries as the payload will always be
treated as an "event" by all parties concerned.
RT> Section 5.1.1 defines what an extension
is and how they should be treated (including conformance statements!).
I fail to see a difference.
In the second example, the MobileDevice is an extension that is not
specified by the protocol. As far as the protocol is concerned it is
some arbitrary data that a vendor/implementor placed possibly for
addressing some use cases not addressed by the protocol. It could be a
MobileDevice or a SailBoat or a FloridaOrange. The spec does not
know/care. Only the vendor/implementor knows/dictates the semantics of
this data. The protocol does not (and should not) say how it ought to be
treated, because the sole purpose of an extension per the way it is
defined currently in the spec is to extend the protocol.
RT> Exactly the same is true of the
event. The protocol defined the contextual semantics for carrying something
where a user defined the precise semantics and syntax of the actual item.
Another way to look at this is to consider the difference between
extending a data model vs extending a protocol. The StormWarning example
coule be treated as extending the WSRP data model. The MobileDevice
example falls in the second category of extending the protocol. Both use
open content models at the data level, but in the latter case,
discussion on both the data type and semantics are outside the spec's
domain.
RT> Both contain minimal elements of
extending the protocol and are primarily extensions of the data model.
With the current proposal, we are trying to add semantics to extensions,
which in my opinion weakens the extension model.
RT> The proposal is to provide a means
by which a protocol user MAY describe the semantics/syntax they have defined
to other parties. There are no additional semantics being defined within
the protocol, merely an in-band technique for transferring metadata.
Subbu
Rich Thompson wrote:
>
> I don't see the distinction you are trying to draw. Perhaps using
a
> concrete example will help. Lets compare someone defining/using a
> "StormWarning" event with someone else defining a "MobileDevice"
> extension. I think the following table accurately describes who defines
> what on the semantic and syntactic levels. In this, I see a lot more
> similarities than differences.
>
> *StormWarning
event*
*MobileDevice extension of ClientData*
> Protocol Defined Semantics
Protocol defines that this is an independent
> notification where the Consumer controls distribution policy (section
> 6.4.2).
Protocol defines that this extension is relevant to the data
> the client has supplied to the Consumer about itself (section 6.1.9
&
> 5.1.1).
> User defined semantics
User defines that the StormWarning event
> notifies recipients of changes in the Weather Service advisories.
User
> defines that this extension element carries extended information about
a
> mobile device.
> User defined syntax
User defines a type describing the event’s
> payload.
User defines a type describing the extension’s payload.
>
>
>
>
> Also, the ExtensionDescription proposal has a similarity to
> EventDescriptions in that the supplying of metadata about the user's
> definitions increases interoperability, but is not required by the
> protocol.
>
> Rich
>
>
>
> *Subbu Allamaraju <subbu@bea.com>*
>
> 08/23/05 09:55 AM
>
>
> To
> wsrp
<wsrp@lists.oasis-open.org>
> cc
>
> Subject
> Re:
[wsrp] ExtensionDescription
>
>
>
>
>
>
>
>
> I can see where we have been disagreeing more clearly now.
>
> In places where we defined open content models, the type of the data
is
> owned by either a Consumer or a Producer implementation, while the
> **semantics are still specified by the protocol**.
>
> The motivation for extensibility is different. It is true that
> extensions do have an open content model, but that is to let protocol
> users (not protocol owners) carry extra data with proprietary semantics.
> The protocol neither defines the type nor the semantics of data
> contained in extensions.
>
> With open content models, as long as the receiving party supports
the
> data types contained, interop is guaranteed since the protocol defines
> the semantics. With extensions, both parties must agree on not only
the
> type, but also the semantics to interoperate.
>
> Regards,
> Subbu
>
> Rich Thompson wrote:
> >
> > The closest I see to a definition in these responses is
distinguishing
> > between open content models and areas where the value that
can appear is
> > an extensible list. But then there follows an attempt to
distinguish
> > between the various open content model areas and I find
the attempted
> > distinction arbitrary.
> >
> > For me, there are three groups:
> > 1. Things defined by the protocol (i.e. in-band)
> > 2. Things not defined by the protocol, but where the protocol
has
> > anticipated additional definitions and made accommodations
to carry the
> > items (i.e. designed extensibility)
> > 3. Things which are not carried by the protocol (i.e. out-of-band)
> >
> > I am willing to have the second group split, provided there
are
> > principled reasons for the distinctions. The particular
manner in which
> > the protocol accommodates carrying an item does not, by
itself,
> > constitute such a principled reason, at least for me.
> >
> > For me, the protocol ought to try and make items falling
into the second
> > group as usable as possible, with the inherent understanding
that such
> > items will always be less interoperable than items falling
within the
> > first group.
> >
> > Rich
> >
> >
> > *"Andre Kramer" <andre.kramer@eu.citrix.com>*
> >
> > 08/23/05 03:43 AM
> >
> >
> > To
> >
"Subbu Allamaraju" <subbu@bea.com>, "wsrp"
> <wsrp@lists.oasis-open.org>
> > cc
> >
> > Subject
> >
RE: [wsrp] ExtensionDescription
> >
> >
> >
> >
> >
> >
> >
> >
> > Like Subbu, I'm differentiating between our protocol "extension"
points
> > where we expect specialization (to avoid the extension
term) such as:
> > properties; events and profiles from the open content models
(now lax
> > processing), which allow undefined payload to piggy back
on our
> > structures. These could be inserted by an intermediate
or passed to/from
> > portlets (without being interpreted by the producer/container).
> > Arguably, SOAP headers are a better model for such "extensions",
but we
> > agreed a long time ago to add multiple "any"s
to all structures, rather
> > than try to define all possible extension points.
> >
> > Regards,
> > Andre
> >
> > -----Original Message-----
> > From: Subbu Allamaraju [mailto:subbu@bea.com]
> > Sent: 22 August 2005 18:32
> > To: wsrp
> > Subject: Re: [wsrp] ExtensionDescription
> >
> > My comments which of these constitute extensibility.
> >
> > Rich Thompson wrote:
> > >
> > > Could you provide a definition for a "pure"
extension of the protocol?
> > >
> > > I would particularly like to see how it applies
to:
> > > - Defining a new value and related semantics
which extend the mode
> > > portion of the protocol
> >
> > Yes, we fine an extensibility model.
> >
> > > - Defining a new type and related semantics
which extend the eventing
> >
> > > portion of the protocol
> >
> > Not related to extensibility. We define ways to carry arbitrary
payload,
> >
> > but that is not the same as an extension point.
> >
> > > - Defining a new type and related semantics
which extend the
> > ClientData
> > > portion of the protocol
> >
> > Same as previous.
> >
> > Regards,
> >
> > Subbu
> >
> >
> > > I see all three of these as places where we
built extensibility into
> > the
> > > protocol, presumably because we expected implementations
to leverage
> > > such extensibility.
> > >
> > > Rich
> > >
> > >
> > >
> > > *"Andre Kramer" <andre.kramer@eu.citrix.com>*
> > >
> > > 08/22/05 12:55 PM
> > >
> > >
> > > To
> > >
Rich Thompson/Watson/IBM@IBMUS, "wsrp"
> > <wsrp@lists.oasis-open.org>
> > > cc
> > >
> > > Subject
> > >
RE: [wsrp] ExtensionDescription
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > I'm opposed to any description of a pure extension
in the protocol -
> > > even transfers of description (which would not
be very useful, unless
> > > backed up by some real description and agreement).
> > >
> > > Regards,
> > > Andre
> > >
> > >
> > >
> > ------------------------------------------------------------------------
> > >
> > > *From:* Rich Thompson [mailto:richt2@us.ibm.com]
*
> > > Sent:* 22 August 2005 17:44*
> > > To:* wsrp*
> > > Subject:* RE: [wsrp] ExtensionDescription
> > >
> > >
> > > Andre Kramer wrote:
> > > > My fundamental concerns are totally
with regards to the definition
> > of
> > > extensions that
> > > > are outside the scope of WSRP. These,
as I understand it, are to be
> >
> > > carried in <extensions>
> > > > elements containing an "any"
value and for reason of future
> > evolution
> > > and extensibility should
> > > > be left open and not described in
our protocol IMHO.
> > >
> > > As far as I know, no one has proposed describing
extensions within the
> >
> > > protocol. What has
> > > been proposed is providing an in-band means
for transferring a
> > > description of an extension.
> > >
> > > Rich
> > > ---------------------------------------------------------------------
> > To
> > > unsubscribe from this mail list, you must leave
the OASIS TC that
> > > generates this mail. You may a link to this
group and all your TCs in
> > > OASIS at:
> > > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> > > ---------------------------------------------------------------------
> > To
> > > unsubscribe from this mail list, you must leave
the OASIS TC that
> > > generates this mail. You may a link to this
group and all your TCs in
> > > OASIS at:
> > > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this mail list, you must leave the
OASIS TC that
> > generates this mail. You may a link to this group
and all your TCs in
> > OASIS
> > at:
> > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this mail list, you must leave the
OASIS TC that
> > generates this mail. You may a link to this group
and all your TCs
> in OASIS
> > at:
> > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> >
> >
> > ---------------------------------------------------------------------
To
> > unsubscribe from this mail list, you must leave the OASIS
TC that
> > generates this mail. You may a link to this group and all
your TCs in
> > OASIS at:
> > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail. You may a link to this group and all your
TCs in OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>
> ---------------------------------------------------------------------
To
> unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail. You may a link to this group and all your TCs
in
> OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. You may a link to this group and all your TCs
in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]