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

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.