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


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



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