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

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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.

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.

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.

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.

With the current proposal, we are trying to add semantics to extensions, 
which in my opinion weakens the extension model.

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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]