I agree with Rich and too fail to understand the objections that are
being raised. For me extensions are a way to express features that we
as a committee either haven't yet understood if/how they are
"universal" enough to be incorporated explicitly into the protocol or
decided that they aren't "universal" enough. I expect and hope
extensions will be used not only narrowly to represent extended
function agreed on by a specific producer and a specific consumer, but
also more broadly to define extensions between a class of consumers and
producers. Examples of this later category include consumers/producers
interested in extra information for new/extended device support [ala
Rich's example], consumers/producers within a particular application
category that have their own conventions/standards [e.g. energy,
insurance, etc], or merely a set of general purpose consumers/producers
that want to push the boundaries of WSRP [as we will always lag].
A primary value I see for describing extensions in-band is by doing so
it allows the consumer to more effectively and efficiently
construct/pass its messages. Without in-band description a consumer
administrator must both have the capability and knowledge to manually
prune the set of extensions sent to any particular producer. What
consumer want to subject an admin/user to such configuration? Without
such configuration, the consumer is left with a decision to either send
all or nothing. As the extension domain grows, sending all can/will
have negative scalability/performance impact on both the consumer to
cosntruct and send the messages and the producer for culling the
desired extensions from the flotsam.
-Mike-
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
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
|