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


Just catching up..
whow, this has drifted very far from the initial request/requirement :-)

I agree with Rich/Mike and find it quite usefull to carry extension
metadata.
This pushes extensions one step further from being a propriatary thing
owned/agreed on by some party to an more interoperable and reusable
concept.
I see use cases where the description can be very usefull, while there are
some where it isn't.
a) The descriptions are usefull when the extension extends the payload and
does not change the protocol flow per se, but adds (on a per message bases)
content to a message.
The user profile items are one of the best examples for me here. It allows
Consumer/Producer to use an extended user profile model in an interoperable
manner (mapping)
b) The descriptions might not be usefull where specific logic extending the
pure protocol flow is being defined since this could not be covered by
additional tooling/mapping.
I would assume most of the extensions to fall into camp a)

1.) Wouldn't, as Andre pointed out, it make sense to have a pointer to the
schema of an extension or even similar to ModelDesc carry it as the
payload?
2.) I think the location[] is quite usefull for a) OurTypes/Names being
carried at varios hierarchy levels in the protocol (example: MarkupParams)
and b) for the logical link enabling to express the extension semantics
(Example: GPS coordinates for Address, both can by business or private).
But rather then defining a String representation or something else,
wouldn't this be a good candidate for an XPath or XPath like expression?

Mit freundlichen Gruessen / best regards,

        Richard Jacob
______________________________________________________
IBM Lab Boeblingen, Germany
Dept.8288, WebSphere Portal Server Development
WSRP Team Lead & Technical Lead
WSRP Standardization
Phone: ++49 7031 16-3469  -  Fax: ++49 7031 16-4888
Email: mailto:richard.jacob@de.ibm.com


                                                                           
             Michael Freedman                                              
             <michael.freedman                                             
             @oracle.com>                                               To 
                                       wsrp <wsrp@lists.oasis-open.org>    
             08/24/2005 07:24                                           cc 
             PM                                                            
                                                                   Subject 
                                       Re: [wsrp] ExtensionDescription     
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           




I agree with Rich and too fail to understand the objections that are being
raised.  For me extensions are a way to express features that we as a
committee either haven't yet understood if/how they are "universal" enough
to be incorporated explicitly into the protocol or decided that they aren't
"universal" enough.  I expect and hope extensions will be used not only
narrowly to represent extended function agreed on by a specific producer
and a specific consumer, but also more broadly to define extensions between
a class of consumers and producers.  Examples of this later category
include consumers/producers interested in extra information for
new/extended device support [ala Rich's example], consumers/producers
within a particular application category that have their own
conventions/standards [e.g. energy, insurance, etc], or merely a set of
general purpose consumers/producers that want to push the boundaries of
WSRP [as we will always lag].

A primary value I see for describing extensions in-band is by doing so it
allows the consumer to more effectively and efficiently construct/pass its
messages.  Without in-band description a consumer administrator must both
have the capability and knowledge to manually prune the set of extensions
sent to any particular producer.  What consumer want to subject an
admin/user to such configuration?  Without such configuration, the consumer
is left with a decision to either send all or nothing.  As the extension
domain grows, sending all can/will have negative scalability/performance
impact on both the consumer to cosntruct and send the messages and the
producer for culling the desired extensions from the flotsam.

     -Mike-


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                      |
|--------+------------------------------+---------------------------------|
| Protoco| Protocol defines that this is| Protocol defines that this      |
| l      | an independent notification  | extension is relevant to the    |
| Defined| where the Consumer controls  | data the client has supplied to |
| Semanti| distribution policy (section | the Consumer about itself       |
| cs     | 6.4.2).                      | (section 6.1.9 & 5.1.1).        |
|--------+------------------------------+---------------------------------|
| User   | User defines that the        | User defines that this extension|
| defined| StormWarning event notifies  | element carries extended        |
| semanti| recipients of changes in the | information about a mobile      |
| cs     | Weather Service advisories.  | device.                         |
|--------+------------------------------+---------------------------------|
| User   | User defines a type          | User defines a type describing  |
| defined| describing the event’s       | the extension’s payload.        |
| syntax | 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


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