[wsrp-wsia] Some issues to discuss at the F2F

[Michael Freedman <Michael.Freedman@oracle.com>]

As time is of the essence I am posting these issues I have asked Gil to
create to the general list so they can be prioritized by the F2F agenda
makers and reviewed by the general members.  Please don't send specific
comments/responses concerning any of these issues until Gil has posted
Issue numbers for them.
    Thanks,
       -Mike-

1)  Move cloneEntity into base interface?

Description:
If issue #57 is resolved to keep our current unified refHandle then
doesn't this mean that CloneEntity has to be in our Base interface?  The
reasoning is that once refHandles exist then CloneEntity has two
purposes.  It both clones the entity and clones the refHandle.  This
means the following permutations are supported:
    a) UserPersistence/Session => clone both entity and session
    b) UserPersisetnce/No Session => clone only the entity
    c) NoUserPersistence/Session => clone only the session
    d) NoUserPersistence/No Session => cloning not supported

Permutation (c) exists if the producer entity isn't clonable but does
have/manage transient state.

We currently have cloneEntity in the Entity interface because we felt
this operation (and the others in this interface) are only necessary if
the entity can be cloned.  However permutation (c) above if a situation
where CloneEntity has meaning but doesn't involve cloning the entities
persistent state.  Thus making the operation a Base operation.

2) Need to investigate WebCollage’s IPR impacts on WSRP

Topic: General
Class: Technical

Description:
WebCollage has posted an IPR statement indicating they have patents and
pending patents that may impact WSRP.  Further details aren't offerred.
Can we get more details so we can access the impact?  When/How will our
organization investigate and report on potential impacts?

3) Interface Optimizations

Topic: Interface
Class: Technical

Decription:
At our last F2F we said we would discuss optimizing our
protocol/interface at the next F2F.  Can we?  I propose 2 optimizations:
    a) performInteraction can return markup
    b) requests carry a "portletID" allowing producers that use shared
sessions to not have to publish dynamic refHandles for the consumer to
manage.

4) Define Soap-Attachment bindings

Topic: WSDL
Class: Technical

Description:
We need bindings defined for Soap-Attachments in our WSDL.

5) Should our sample implementation only implement/support JSR 168?

Topic: Sample
Class: Technical

Description:
The last proposal was for the WSRP sample implementation to support both
JSR 168 and a proprietary Java container mechanism.  Now that JSR 168 is
equal/ahead of us shouldn't we only publish a sample that implements JSR
168?

6) Require urlType come at the beginning of the consumer rewrite syntax:

Topic: Markup
Class: Minor technical

Description:
Currently the producer is allowed to put the urlType token anywhere in
the sequence of tokens it writes into a Consumer rewrite URL.  I propose
we require producers write this token first.  This allows the consumer
to write the most efficient single pass parser.  This optimization is
important as the cost occurs during aggregation.

7) MarkupType in MarkupParams should be an array:

Topic: Interface
Class: Technical

Description:
The MarkupType field in MarkupParams should be an array.  The array
values indicate the mime-types it is acceptable to return with the first
element in the array being the preferred type.  This corresponds to HTTP
semantics and allows a consumer to do mime-type mapping.  A common usage
is to say I support HTML and XML where what I mean is HTML is preferred
(its what is returned to the client) but if you send me an XML response
that self references a stylesheet that generates HTML, I will process
this response to get the HTML for the final response.  There are other
less common situations where portals may want to translate from a
specific markup to another.

8) Can data sent via SOAP-Attachements be encoded differently then SOAP message?  I.e. we say the markup must be in the same charset but this isn’t true if use soap-attachments.  Why force/expose this in our protocol?
 

Topic: Interface
Class: Technical

Description:
Can data in Soap-Attachments have a different encoding then message
body? If so how does this affect our statement that markup [response]
must be encoded based on how the message body is encoded?  Shouldn't we
allow distinct encodings and therefore carry the encoding information?
If so I would make this information an optional return value -- if
excluded then the consumer can safely assume that the attachement has the same encoding.

9) Should GetProperty/SetProperty take locales?  –

 
Topic: Interface
Class: Technical

Description:
Should Get/SetProperty take locales?  I.e. do we need to account for
consumers/producers storing multiple values for a property passed on
locale?  Simple usage case is a consumer that supports a shared portlet
[all users see the same portlet].  In this usage the page
designer/administrator customizes the portlet for all these users.  If
this Portal is running in a multi-national environment isn't it
reasonable for the consumer/adminsitrator to want to store per locale
values?  If so should this be done within the context of a single
entity?

10) Use a soap fault to indicate a redirect:

Topic: Interfaces
Class: Minor technical

Description:
Returning a redirectURL in the InteractionResponse is screwy semantics
because you can also return all the other information.  I would prefer
this act more like a web redirect.  I.e. use a Soap Fault to carry the
redirect.  If we need to pass new entity information along with the
fault so be it -- merely carry it in the fault message.

11) Provide a clear list of consumer requirements and producer requirements.

Topic: Interfaces
Class: Editorial

Description:
Given that many behaviors are optional its very difficult to read the
specification and understand what a consumer is required to do and what
a producer is required to do.  This makes it difficult to figure out if
the specification is complete and whether it will meet its goal in
supporting broad interoperability.  Can we add a section in the
specification devoted to listing the consumer/producer requirements
spread out through the document.  This should even cover the
conditionals.  I.e. requirements of the form "if a consumer supports X
it MUST ...".

12) Need to define format of consumerVendor field in Registration Data,
 

Topic: Registration
Class: Minor Technical

Description:
We need to define the format for the consumerVendor field in
Registration Data.  Suggest we follow JSR 168's lead and say "The string
should start with vendorname.majorversion.minorversion".

13)   Related to issue 42: We should remove userProfileExtensions, consumerExtensions, and registrationProperties from RegistrationData and registrationProperties field in ServiceDescription.
 

Topic: Registration
Class: Minor technical
Related Issue: #42

Description:
The userProfileExtensions, consumerExtensions, and
registrationProperties fields in  RegistrationData and
registrationProperties field in ServiceDescription look like they are
mechansims for carrying extension information.  Are they?  If so they
should be removed in deference to using the extension field.