RE: [wsrp][wsia][wsrp-wsia joint interfaces][Draft Spec 0.43]Terminology

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

The WSIA requirements call for us to support persistent sets of data, so I
would prefer that we pick a name that is meaningful in both TCs rather than
ending up with 2 more specific names.



                                                                                                                     
                      "Eilon Reshef"                                                                                 
                      <eilon.reshef@webc        To:       Rich Thompson/Watson/IBM@IBMUS,                            
                      ollage.com>                <wsia@lists.oasis-open.org>, <wsrp@lists.oasis-open.org>            
                                                cc:                                                                  
                      05/22/2002 10:03          Subject:  RE: [wsrp][wsia][wsrp-wsia joint interfaces][Draft Spec    
                      PM                         0.43] Terminology                                                   
                                                                                                                     
                                                                                                                     
                                                                                                                     



A taxonomy question mainly to the WSRP folks (Thomas, Mike, ...).

I think everybody is pretty much on the same page with regards to the term
"session" which identifies the transient state. (And, as Rich noted, to
people that come from an OO background, this would be the same as an object
instance).

The tougher one is the persistent key, which in WSRP is typically referred
to as "instance", but as Rich noted this may be non-intuitive to people
from an OO background (who think of transient object instances), and hence
the need for a new term.

Would you find the following, radically simplified, suggestion for an
operation name intrusive:

createPortlet

Along those lines, a portal would call the operation createPortlet, would
get back a (persistent) portletID and then (optionally) call createSession
with the portletID.

Note that using this taxonomy, a portlet is the "last persistent instance".
So, multiple instances of the same mail portlet are multiple portlets.

A few justification points:
1. IBM's RPWS proposal used the term createInstance. However, clearly the
term "instance" is meaningless by itself - an instance is always an
instance of something, in this case I assume the intent was a shortcut for
createPortletInstance. Hence, createPorlet conveys a similar meaning.
2. The ability to create a persistent key seems to be only under the scope
of WSRP and not under WSIA. WSIA supports a persistent key to create
sessions and to subsequent operations, but wouldn't probably deal with how
they are created and management (with all the associated issues that are
well described in Mike's latest summary). Hence, the motivation to use a
portal-specific name.

Any thoughts from hard-core portal people?

      -----Original Message-----
      From: Rich Thompson [mailto:richt2@us.ibm.com]
      Sent: Wednesday, May 22, 2002 3:26 PM
      To: wsia@lists.oasis-open.org; wsrp@lists.oasis-open.org
      Subject: Re: [wsrp][wsia][wsrp-wsia joint interfaces][Draft Spec
      0.43] Terminology




      Presuming the 2nd case to get dropped relative to the previous set of

      emails, I would propose this section call out how we will refer to
      these
      things throughout the remainder of the document/API. In particular, I
      would
      suggest:
            Session Information - This is carried opaquely in the interface
      as a
            "sessionID".
            => goes away
            Persistent Information - This is carried opaquely in the
      interface as
            a "handle".


      Rather than "Manifestation", I would propose using "Entity" to
      describe the
      thing from which markup may be requested. I think it has the right
      level of
      opacity (Consumer has no idea what kind of entity it is) while
      carrying
      appropriate semantics (a thing that may be interacted with). Using
      these
      terms, there was also an open question at the end of our last call
      related
      to whether there were both persistent and transient entities ...


      If we are going to support explicit lifecycle for both of these, I
      would
      propose:
         handle   createEntity(handle, propertyValues)
         sessionID   createSession(handle, propertyValues)







      ----------------------------------------------------------------
      To subscribe or unsubscribe from this elist use the subscription
      manager: <http://lists.oasis-open.org/ob/adm.pl>