RE: [wsrp] ExtensionDescription

[Rich Thompson <richt2@us.ibm.com>]

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