[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrp] ExtensionDescription
Comments in line. Subbu > In your example below, protocol extensions are treated the same as open > content models used within the protocol, and this has been my concern. > RT> If you think there is an error is how the table describes who > defines what, please point it out as I think the distinctions it makes > in this area are correct and similarities obvious (I see some handler > along the way destroyed the table layout in the copy below. Let me know > if it didn't appear in the original email as a table and I will post it > as a document instead.). There was no question of formatting. Sorry if I had implied something like that. > 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. > RT> Section 5.1.1 defines what an extension is and how they should be > treated (including conformance statements!). I fail to see a difference. True, it defines it as a means for spec users (not owners) to extend the protocol. It does not say that extensions just extend the data model. > 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. > RT> Exactly the same is true of the event. The protocol defined the > contextual semantics for carrying something where a user defined the > precise semantics and syntax of the actual item. Sorry, I must disagree. This is not the case with an event. The spec defines what an event how it must be carried. I see a clear difference between spec defined semantics and spec user defined semantics. > 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. > RT> Both contain minimal elements of extending the protocol and are > primarily extensions of the data model. Not unless we go with this proposal. Extensions extend both the data model and the semantics - not just the data model. In fact, with extensions, the semantics are as important (if not more) as the data model. > With the current proposal, we are trying to add semantics to extensions, > which in my opinion weakens the extension model. > RT> The proposal is to provide a means by which a protocol user MAY > describe the semantics/syntax they have defined to other parties. There > are no additional semantics being defined within the protocol, merely an > in-band technique for transferring metadata. > > 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 > > > --------------------------------------------------------------------- > 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]