I do think there is a concrete difference
between events and extensions:
Events are (mostly) a way to pass data between
different portlets on the same page, while extensions are (mostly) a way to
pass data between the producer and the consumer. That makes for a huge
difference on the kind of use cases for them, and the amount of in-band metadata
needed.
Yossi.
From: Rich Thompson
[mailto:richt2@us.ibm.com]
Sent: Thursday, August 25, 2005
4:04 PM
To: wsrp
Subject: Re: [wsrp]
ExtensionDescription
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
--------------------------------------------------------------------- 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