[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]