Issues Agenda Monday AM –133, 93, 121 –132 –122, 94 –126 Monday PM –123 –124 –125...

Issues Agenda• Monday AM

– 133, 93, 121

– 132

– 122, 94

– 126

• Monday PM– 123

– 124

– 125

– 127

– 119, 136

• Tuesday AM– 6– 7– 68– 92

• Tuesday PM– 74– 110– 57– 85– 48– 120

Issues Agenda• Thursday AM

– 102

– 111

– 118

– 129

• Thursday PM– 59

– 130

– 105, 115

– 66

– 101

– 117

– 139

• Wednesday AM– 97– 45– 100

• Wednesday PM– 91– 35– 96– 138– 37, 128– 63– 114

#133 - extensions typing

• JSR168 uses String and String[] as the only extension types• WSRP uses <any namespace=“##other”/> from schema.• Since the JSR168 types are a subset, the remaining issue is

JSR168 exploiting other supplied types. This requires either “knowing” a class that can be used, or generating one based on a schema for the type. WSRP encourages all extensions to be typed so that all users of the extension can process it safely.o Correlated: #93 – Payload extensibility mechanism

v0.7 changed from typed Property[] to introduce <any/> as this is the base schema mechanism for carrying such extensions. V0.8 has morphed this slightly to accommodate JAX-RPC RI restrictions (used in products?) for interoperability of both the WSDL and runtime messages.

o Correlated: #121 - user-info extensions being <any>

#132 - Valid portletModes and windowStates on performInteraction() and getMarkup()

• JSR168 uses container validation that a transition will be legal while building an URL

• WSRP uses Consumer access control to process requests for transitions

• In general this would entail passing a full XACML (access control markup) that may require a reference to some logic (hopefully via a web service call). This proposal is for a subset … distinct & independent vectors of valid next modes and window states. – Resolved: add arrays to MarkupParams. Add entity metaData.

Shoulds => assist in generating UIs valid for the End-User.

#123 - portletModes per markup

• JSR168 allows portlets to define their valid modes per markup type

• Do we need a MarkupTypeContext? If so, what all goes in it?– Resolved: move metadata into an array of structures

where each structure is per markupType & contains validModes and validWindowStates.

• String markupType

• String[] modes

• String[] windowStates

• Extension[] extensions

#125 - clone-on-write

• JSR168 has cloning as container functionality• WSRP semantics may involve the entity in the clone semantics• The current clone-on-write semantics are an example for

JSR168 where the portlet may be involved as the clone happens during the portlet invoking an operation on the container. The portlet would have to be prepared for the configuration record having been marked as read-only such that the invocation throws an exception.

• JSR168 does not anticipate the configuration being read-only.• Also note that the container would have to manage an

indirection for the configuration record in order to deal with the case of cloning because a write occurred. It has also been pointed out to the JSR leads that a portlet may store a portion of its persistent state somewhere other than the container managed properties and therefore a mechanism for it to be involved in the cloning operation should be available.

#127 - setting properties not defined in type definition

• JSR168 allows portlets to set properties that do not currently exist

• WSRP requires Consumers to only set properties that are described.

• v0.8 added “While it is possible this set of properties change with time (entity dynamically creates new properties), Producers/entities SHOULD make the returned modelDescription as complete [static] as possible.” in section 7.7. – Equivalent language at EntityDescription level

#119 - Portlet Mode and Window State constants, name change

• JSR168 does not include the redundant _MODE and VIEW_ portions of WSRP nameso Correlated: #136 - Nicer naming convention for constants + scoping of

them Do we want these to be all caps? Do we want to prefix them for namespacing purposes?

Resolved Drop redundant portion Make lower case

#115(2nd) – CSS prefix

• Proposed resolution:change “wsia-” to “markup-”– Resolved:

• portlet – 11111 (5)

• fragment – 1111111111111 (13)

• markup -

• markup-fragment – 11 (2)

• abstain – 11 (2)

#152 - Format for consumerVendor field in Registration Data

• 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“– Resolved:

• rename to consumerAgent• productname.majorversion.minorversion other_words

Pending resolutions

• 19 - Verbiage around usage of initEnvironment() added. • 23 - MarkupParams has requestParameters in v0.8• 84 - Add a string clientAuthType. Describe both this and

secureClientCommunications as carrying the End-User to server connection information only regardless of the number of connections between the End-User and the Consumer (none[null], basic, digest, certificate, form, …).

• 90 – move templates into MarkupParams• 104 – Multiple means of Consumer supplying identities recognized in the

language … change to 10.2 “MAY request” … rename profileKey to userContextID [4.1.3] & remove extra verbiage

• 106 - Draft v0.81 (small grammar update) describes an entityHandle in section 7.1.4 as "An opaque and invariant handle, unique within the context of the Consumer’s registration, which the Producer is supplying for use on future invocations targeted at the new entity.“ … add language for no registration case.

• 108 - entityStateChange default value is now "OK". Change to making this a required field … no default

• 109 – modified clone-on-write semantics reverted this to entityHandle

• Resolved Monday

– 19, 23, 84, 90, 93, 104, 106, 108, 109, 115.2, 119, 121, 123, 124, 125, 127, 132, 133, 136, 152

• Tuesday AM– 6– 7– 68– 124– Proposed runtimeContext– 122, 94, 143a– 126– 92

•Tuesday PM–74–110–57–85–48–120

#6 - Is groupId required?

• Current draft: o EntityDescription contains a groupIDo ProducerDescription contains a flag called

doInitEnvironmento If doInitEnvironment=’true’, the Consumer MUST invoke

initEnvironment once per groupID per user session as the Consumer defines it

o initEnvironment says what groupID it is foro Consumer MAY be required to manage cookies (Producer

flag) • Do we want a protocol level field for non-cookie use?

– no

o If an operation faults with InvalidEnvironment, Consumer MUST reinvoke initEnvironment().

o Resolved: Drop groupID from initEnvironment. No groupID => in “” group

#7 - the Consumer must group together in the same shared context all of the portlets that it is aggregating on behalf of a single End User

session

• depends on entity metadata

#68 - Do we need initEnvironment

• Sept F2F said ‘Yes’– Resolve:

• Rename as initCookie

• Metadata requiresInitCookie => no, perUser, perGroup• Drop groupID from initCookie. groupID => required for requiresInitCookie == perGroup

• Add optional entityInstanceID – collect with refHandle

#124 - concept of window ID

• JSR168 introduces a windowID to enable portlets to namespace multiple instances of themselves within a shared session.

• This seems like a particular Producer to entity issue. Key question is whether means are provided for the Producer to supply the functionality. Choices include:

• 1. Producer manages creating a unique id and encodes it in the refHandle for subsequent invocations.

• 2. Producers not using refHandles could exploit the fact that JSR168 Producers are going to set requiresCookieSupport to ’true’. In addition to the JSessionID cookie that will be shared by all portlets in a portlet application, a portlet specific cookie could certainly be used to store this unique id. – Correlated: #143b - carry a "portletID“ …

Proposed new Consumer runtime rendering context

• Topic: Missing rendering context and runtime environment identification

• Description: JSR 168 requires identification of runtime views of entities (see issue #124). Additional runtime information is also common and valuable. All these can be collected in a new Runtime(Render)Context structure:

• ProtocolStructure: RuntimeContext [R] { [R] String portletId; // Consumer rendering instance identification[O] String layoutId; // Consumer page aggregation / layout group identifier.[R] Any environmentId; // Producer-side shared session tracking blob[O] Any extensions; }

• ProtocolMethods affected:– (environmentId, extensions) <-- initEnvironment(registrationContext,

groupID);– interactionResponse <-- performInteraction(refHandle, runtimeContext, ...);– markupResponse <-- getMarkup(refHandle, runtimeContext, ...);– possibly deleteRefHandle(>0.8) also

Proposed new Consumer runtime rendering context

• The consumer MUST return the environmentId, as returned by (groupId determined) initEnvironment(), in a RuntimeContext element on each (initEnvironment grouped) performInteraction and getMarkup. The consumer SHOULD (a JSR 168 MUST) supply a unique identifier that indicates the client side view(s) that the entity is being rendered into (or for the locus of interaction). The consumer MAY provide additional layout information that uniquely identifies the layout grouping the view is contained in, using the layoutId field in the supplied RuntimeContext. The portletID and layoutID ids SHOULD be unique in the context of a consumer (MAY be URIs or uuids).

#122 – Mismatch with JSR definition of Action

• JSR168 allows state changes in getMarkup()• WSRP restricts state changes to performInteraction()• Choices include:• 1. Allow state changes in getmarkup(): impacts other decisions we have

made• 2. Require JSR168 Producers map between these protocols. Not clear that

this can be done in a deterministic manner.• 3. Relax WSRP requirement to “no state changes may be sent to the

Consumer from getMarkup()”. Could also add a statement about desirability of repeated getMarkup() invocations returning the same markup.

• Resolved: Introduce a nonBlockingInteraction(). (perform & performBlocking)

– Correlated: #94 - getMarkup() able to modify/return state • Resolved: Relax requirement as per #3

• Correlated: #143a – allow all performInteraction() variants to return markup as an optimization– Resolved: yes

Impacts Consumer managing persistent state

Doesn’t impact Consumer managing persistent state

Impacts other entities

Current performInteraction

Current performInteraction

Doesn’t impact other entities

Proposed non-blocking actions

Current getMarkup

#126 - uploading data in both markup operations

• JSR168 allows uploading in both performAction() and render()

• WSRP only passes uploaded data to performInteraction()

• What would be the impact of adding these fields to getMarkup()? Certainly a big increase in payload size. What about redundant sends?– Resolved: Only the performInteraction variants

#92 - Maximum size of a handle

• Choices (Straw poll=> 3, 6, 4, 9):1. <255 bytes. This makes it directly usable as a

DB key and yet long enough for security and encoding multiple GUIDs

2. <4K bytes. This constrains memory usage for the Consumer while allowing limited use of URI schemes.

3. unlimited. This treats handles as URIs4. No stated limit. Add Producer metadata

declaring limit the Producer implements.Resolved: #1

#110 - destroyEntity failure semantics

• Do we want to introduce a return type to carry failed destroys?– 1. Make it singular. Return NonExistentHandle fault

if previously released handle is supplied.• 6

– 2. Alternative: Plural, but non-atomic … use fault message to carry failures if possible.

• 6

– 3. Leave as is• 1

– Resolved: #2

• Resolved

– 6, 7, 18, 19, 23, 68, 84, 86, 90, 92, 93, 94, 104, 106, 108, 109, 110, 115.2, 119, 121, 122, 123, 124, 125, 126, 127, 132, 133, 136, 143, 152

• Wednesday AM– 97– 45– 100– 140– 149– 91– 120

•Wednesday PM–35–96–138–129–146–37, 128–63–114

#97 - Caching Mechanism

• Proposals:• 1. Scheme in v0.7 & v0.8 – expirary & rules (userProfile,

registration, markupParams)2. Modified proposal from Yossi that treats items from current draft as scopes and introduces InvalidationKeys. – Resolved:

• MarkupParams includes validateTag

• MarkupResponse includes CacheControl; namely:– [O] expires

– [O] userScope (forAll, perUser)

– [O] validateTag

– [O] extensions

• Key must include markupParams

• perUser scope should include changes to User data as this might not flow to the Producer when it changes.

• validateTag used for validation when expires has passed.

#45 - Signaling state change in InteractionResponse

• How “sticky” is navState? Extremes = zero and Consumer-user session.– Consumer manages navState in a manner that allows the

user to get the same page for the duration the Consumer chooses (at a minimum for the Consumer’s page).

• Does a null mean keep current (v0.8 semantics) and thereby require the Consumer to manage this between user invocations or does it mean no state? Even in the second case, the Consumer MUST remember the last navState (for example) in order to properly handle a page refresh. – Make navState required (null not available) … bookmarking

comment

#91 Is setEntityProperties atomic?

• Customization subgroup decided it should be atomic. – Validated and synchronized update, but not

required to be transactional.

#120 - PropertiesDescription not in entityDescription, why?

• Will enough Consumers want this information to place it in EntityDescription? – no

#35 - Is recommend strong enough for URL-encoding statement?

• Mike & Sasha have been working on clarifying this … choices:– 1.Add well-known parameter name:

• wsia:charSet – indicates the character set the URL was encoded in (i.e. how the %hh was derived).

– 2. Leave as is (UTF-8).

• Resolved: #2

#96 - Review well known URL parameter names

We have:• wsia:navigationalState - sets this for the entity• wsia:mode - requests mode change before invocation• wsia:windowState - requests windowState change• wsia:urlType - how to process the activation of the url• wsia:url - the url for when wsia:urlType=Resource• wsia:token - the token for when wsia:urlType=NameSpace• wsia:secureURL - the rewritten url should use secure

communications• wsia:rewriteResource - flag indicating whether the

Consumer must parse the indicated url for url rewriting• wsia:requestParameters - Producer url writing place to

put arbitrary requestParameter list• Drop - wsia:refHandle - Producer url writing place to place refHandle for the resulting invocation.

#138 – URL Templates for performInteraction()

• Should URL templates be available in performInteraction, e.g. for redirect logic or for saving computed URLs in the session during action processing? Could then be included in MarkupParams and not as an additional parameter to getMarkup().– Resolved – yes.

#129 - double encoding of wsia:url

• Issue proposes having the Consumer do this, but the Consumer can’t parse the needed info in order to do the double encoding.

– Resolved: Producer needs to do strict encoding – same as other wsia:parameters

#146- Require urlType token at beginning of URL sequence

• 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.

• /wsia:rewrite?urlType&wsia:url=….

– Resolved: do it … reorganize descriptions by urlType & then common parameters.

#131- wsia:requestParameters should encode ‘&’ and ‘=‘

• Current language:"The value replacing wsia:requestParameters should follow the pattern of a URL query string (properly encoded name/value pairs separated by the ‘&‘ character) and be strictly encoded as it likely will be the value of a parameter in the query string of the full URL.“

- change ‘doubly’ to ‘strictly’

#37 & 128 - Using predefined namespaces prefixes is unconventional

• Switch to xxxx- or stay with xxxx:?

• What will xxxx be? (planned for Friday discussion)

• Resolved, use ‘xxxx-’ instead.

#63 - Entities / Window States

• What Modes do we want to support? Require?– View

– Edit

– Help

– Config

– Preview

• What Window States do we want to support? Require?– Normal

– Minimized

– Maximized

– Solo – Normal use => Entity popped up window showing just the entity. This informs Consumer/entity that “popup style” are in use.

• Resolved: View & Normal required of entities. Plan to resolve #102 by deleting Config.

• Semantics of refusal to change windowState?

#114 - Should custom roles, modes & window states use namespacing?

• URIs are encouraged in current draft.

• Resolved: don’t bother

#102 - What is the difference between EDIT mode and CONFIG mode?

• Roughly CONFIG mode is EDIT mode with producerRole=”Administrator”. I think CONFIG mode was introduced for case where the entity did not need to be involved in the processing of an update.

• Resolved: Delete CONFIG

#48 - Should an entity say that it is cloneable?

• Sept F2F said “No” … Producer level and indicated by exposure of EntityManagement portType

– Resolved: no

Pending resolutions

• 105 - Add releaseRefHandles(refHandle[], registrationContext) to the Markup portType. – resolved: add it for now

• 115 - Add paragraph to section 9 describing difficulties in using method=get– Resolved:

• 1. Consumers SHOULD support method=get: • 2. entity metadata field for usesMethodGet:

– www.consumer.com/rp_{wsia:requestParameters}/…

– www.consumer.com/rp_/…

• 98 – Should operations (other than getProperty) return Entity property values? [No]

• 99 – Should property operations take a user context? [yes]

#150 - Use a SOAP fault to indicate a redirect

• Returning a redirectURL in the InteractionResponse is screwy semantics because you can also return all the other information. Could 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

• Resolved: Divide InteractionResponse into a choice … normal semantics or redirectURL (deal with new entities and refHandles in both cases).

#111 - getMarkup called for MINIMIZED

• Gil’s suggestion:

“When the window state is MINIMIZED, the entity SHOULD NOT render visible markup in this case, but is free to include non-visible data such as javascript or hidden forms. The Producer MUST expect the getMarkup() operation to be invoked for the MINIMIZED state just as for all other window states.”

#118-RegistrationData.customUserProfileData[]

needs a description sub-element

• Does this want to include a means to locate a type for the extensions?

– Resolved: Leave as String[]

#130 - minimial encoding of Url rewriting params

• Examples should encode only ‘&’, ‘=’, ‘?’, and ‘/’.

– Check for ‘:’ …

#101 - Valid values for MarkupParams fields

• Are the v0.8 draft references/examples acceptable? Specific additions/subtractions?

– Email specific changes to Rich

#117 - markup Interface should be the first described in the spec

• ServiceDescription is the other required interface and logically is used before the markup interface.

• Current order: – ServiceDescription– Markup– Registration– EntityManagement

– Resolved: Keep order

#153 - Remove "extension" fields from ServiceDescription and

RegistrationData• 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.

– Make ServiceDescription.registrationProperties of type ModelDescription … note that these are not endpoint properties but properties of a registration

– Drop consumerExtensions– Rename userProfileExtensions (customUserProfileData?)

#137 – Require “DefaultTemplate“?

• Templates aren’t used at all unless doesURLTemplateProcessing == true.

• Should even then only be mandatory if not all of the other templates are being supplied– Resolved:

• Add language to this effect• No default values needed as Consumer MUST send ….

#151 - Provide a clear list of consumer and producer requirements

• 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 ...".

• RT: Suggest this is a separate document from the spec to provide guidance to implementers.

#139 – Delete unused glossary terms• Action (Keep as an indirection to Interaction)

• Anonymity• Company• Host• Login• Logon• Logout• Logoff• Portal Application• Portal Modes• Portlet Application• Portlet Class• Portlet Container• Portlet Content• Portlet Instance

• Portlet Object• Portlet Window• Portlet Window Instance• Principal• Provider• Pull• Push• Service (we use Web Service)

• Service Attribute• Service Offer• Service Option• Service Provider

#134 - use of the GUEST role

• What is the value of a request carrying a GUEST role over a request that carries a ‘’ profileKey?

•There are portals that do this today

• Is there a profileKey for an unauthenticated user (e.g. can the profileKey==“” or multiple users share the same key)?

•yes

• Resolved

– 6, 7, 18, 19, 23, 35, 37, 45, 48, 63, 68, 84, 86, 90, 91, 92, 93, 94, 96, 97, 98, 99, 101, 102, 104, 105, 106, 108, 109, 110, 11, 114, 115, 115.2, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 136, 137, 138, 139, 143, 146, 150, 151, 152, 153

• Thursday AM– 140, 149, 100– 147– 144, 148– 59

• Thursday PM– 85– 74– 57, 142– 66– 141– 145

#140 Internationalization of property and entity descriptions

• <entitydescription>

<shorttitle xml:lang=“en”>Short entity title</shorttitle> <!– tool issues -->

<shorttitle xml:lang=“en” value=“Short entity title”/>

<shorttitle xml:lang=“fr” value=“French text”/>

</entitydescription>

OR

• <entitydescription xml:lang=“en” localizationURL=“…”>

<shorttitle resname=“abc”>Short entity title</shorttitle>

</entitydescription>

Separate resource contains:<localization>

<resource resname=’abc'>

<value xml:lang='en'>English text</value>

<value xml:lang='fr'>French text</value>

</resource>

</localization>

1. Inline: 17

2. Separated: 3

Abstain: 2

Indirect through resources?

Yes: 12

No: 7

Abstain: 4

#140 Internationalization of property and entity descriptions

• Example use for property descriptions is:• <model xml:lang=“en” localizationURL=“…”>

<propertydescription name="p1" type="xsd:string” label=“Property 1”

hint=“this is a few sentences for some tooltip”

label-resname=“xyzzy” hint-resname=“abccd”/> ...

</model>• <wsrp:localization>

<resource resname=’xyzzy'> <value xml:lang='en'>English property 1 label</value> <value xml:lang='fr'>Label de property un</value></resource>...

</wsrp:localization>

#149- Should Get/SetProperty take locales?

• Why localize the values?• Resolved: don’t

• In the get____Description operations.• Resolved: Operations take both a desiredLocales[] and

sendAllLocales flag

#100 - Entity property representation, serialization, and extensibility

Proposed property description from the 0.8 draft.• <Property name=“xxx” >

Property’s value</Property>

• <PropertyList> <Property /> <!– 0-n --> <ResetProperty /> <!– 0-n --> <extensions /> <!– 0-n --></PropertyList>

• <PropertyDescription name=“xxx” type=“a_Qname” label=“Property 1” hint=“Perhaps a tooltip” label-resname=“xyz” hint-resname=“abc”> <extensions /> <!– 0-n --></PropertyDescription>

• Define this coupling for localized attributes

• <PropertyDescription name=“xxx” type=“a_Qname”><label resname=“xyz” >Property 1</label> <hint resname=“abc”>Perhaps a tooltip</hint><extensions /> <!– 0-n -->

</PropertyDescription>• Use this format for PropertyDescription• Capitalize as per rest of structures

• <ModelDescription xml:lang=“en”> <PropertyDescription /> <!– 1-n --> <schema /> <!– would like this to be xsd:schema! --> <extensions /> <!– 0-n --></ModelDescription>

#100 - Entity property representation, serialization, and extensibility

Proposed property operations from the 0.8 draft.

entityResponse = setEntityProperties(entityHandle, registrationContext, entityContext, userContext, propertyList);

propertyList = getEntityProperties(entityHandle, registrationContext, entityContext, userContext, propertyList);

propertyList => names

modelDescription = getEntityPropertyDescription(entityHandle, registrationContext, entityContext, userContext, desiredLocales,

sendAllLocales);

#147- MarkupType in MarkupParams should be an array

• 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. – Resolved

• The order is the order of preference• Use http definition of * and /*• Encourage, but not require one of these mime types is returned.

• Locale as well?– Resolved

• yes• MarkupResponse needs markupType & locale

#144 - define bindings for attachment mechanisms

• We need bindings defined for these in our WSDL.– Attachments allow portions of what is transferred to use a

different encoding.• Resolved: Once WSDL subgroup finishes base definitions … in v1

– Correlated: #148 - Can data in attachments have a different encoding then message body?

– Should the type of the markup field be base64Binary? (no)

#59 - Interface discovery

• Currently spec implies the types of interfaces offered by a service are described by the service itself (via a reference to the wsdl). Is this really what we want? Or should the types of interfaces be determined by talking to the wsdl directly? Is getServiceDescription() supposed to describe a Producer or a Producer's interfaces or both?

• Sept F2F => wsdl field retained. If information was gathered prior to calling getServiceDescription() [by using out of band mechanisms], it can be ignored.

• Drop from ServiceDescription (9-9 tie vote, 3 abstentions … see if there are new votes on 11/14)

• Drop from EntityDescription (yes)

#85 - refHandle/expires MUST/MAY contradiction

• Current language:“A new transient and opaque handle the Producer is supplying for use on

future invocations for this use of the entity. The Consumer MUST use this new value as the refHandle on subsequent invocations until either the Producer supplies another refHandle or the refHandle is becomes invalid by either the refHandleExpires duration expiring or a fault message from the Producer [A206]. Note that failures to use this handle on subsequent invocations (e.g. something exceptional caused the Consumer to lose track of it) will result in a loss of state and likely unexpected behavior for the End-User. If the refHandleExpires duration has elapsed, but the Consumer did not clean up its resources related to the refHandle, the Consumer SHOULD supply the expired refHandle to the Producer for processing. If the Producer has also not cleaned up related resources, this processing can avoid a loss of state. If the Producer has already cleaned up resources, it SHOULD ignore the invalid runtime refinement on the entityHandle and process the invocation as if the refinement had not been supplied, likely including the return of a new refHandle in the response. ”

-Replace italized text with description of what happens when a refHandle is not returned and what a Consumer SHOULD do when dropping a refHandle.

#74 - Should the Consumer MAY or MUST destroyEntities?

• Must attempt language appears to have gotten removed (was not intentional :} ). For both deregister and destroyEntities, do we want:

1. “Consumer MUST attempt to release the handle by invoking ____.”• The Consumer MUST NOT consider the handle released by the Producer until the

releasing operation indicates success.

2. For destroyEntities, use fault or create a return type to carry an array of failures (failedHandle, faultCode, extensions).

#57 - Unification of session and entity handles

• Draft v0.7 introduced this unification.

• Draft v0.8 refined this as entityStateChange proposal was refined. – Correlated: #142: Move cloneEntity() to base?

• If cloneEntity() takes a refHandle, shouldn’t it be in the base?– V0.8 changed this back to entityHandle and removed the cloneSession

semantics. Consumers wanting that semantics MUST set entityStateChange to ‘Clone’.

» Keep both as is

#66 - Interface details

• ServiceDescription portType– serviceDecription = getServiceDescription(registrationContext,

userContext);

• Markup portType– markupResponse = getMarkup(registrationContext, entityContext,

runtimeContext, userContext, markupParams);

– interactionResponse = performInteraction(registrationContext, entityContext, runtimeContext,

userContext, markupParams, interactionParams);

– performBlockingInteraction()– returnAny = releaseRefHandles(registrationContext, refHandles[]);– returnAny = initCookie(registrationContext);

#66 - Interface details

• Registration portType– registrationContext = register(registrationData);

– registrationCore = modifyRegistration(registrationContext, registrationData);

– ReturnAny = deregister(registrationContext);

• EntityManagement portType– entityDescription = getEntityDescription(registrationContext,

entityContext, userContext);

– entityResponse = cloneEntity(registrationContext, entityContext, userContext);

– ReturnAny = destroyEntities(registrationContext, entityHandles[]);

#66 - Interface details

• EntityManagement portType (cont.)– entityResponse = setEntityProperties(registrationContext,

entityContext, userContext, propertyList);

– propertyList = getEntityProperties(registrationContext, entityContext, userContext, names);

– modelDescription = getEntityPropertyDescription( registrationContext, entityContext,

userContext, desiredLocales[], sendAllLocales);

Combined Issue: Session/Entity handle and maximum length

This was deferred from the beginning of the week, and included consideration of whether to separate the refHandle into individual entity and session handles in the signatures.

Three options were debated:• 1. sessionID<255 bytes and separate (11 votes)• 2. <4K and unified (7 votes)• 3. Abstain (keep unified, no length restrictions) (3 votes)

– Resolved: #1

#141 - Impact of WebCollage's IPR

• Desire expressed to have WebCollage publish licensing terms.– Waiting on WebCollage response

• IBM?? – likely to be similar to ebXML CPPA

#145 - Should our sample implementation only implement JSR 168?

• The last proposal was for the WSRP sample implementation framework that could support both JSR168 and other Java containers. Now that JSR168 is equal/ahead of us shouldn't we only publish a sample that implements JSR168?

Emailed items• Markup encoding vs message encoding (e.g. markup=Shift-

JIS while message=UTF-8)– Attachments (or new MarkupResponse field?)

• Should Fault codes use our types namespace and drop the leading ‘WSRP’?– yes

• List Fault codes with operations– yes

• Is Extension[] needed everywhere?– yes

• Other metadata?o JSR168? - noo GetMarkupIsIdempotent? - noo MustBeCloned? - noo ?

• What will the xxxx in xxxx- be? (have wsrp & wsia placeholders in various places now)

1. WSRP – Web Services for Remote Portals

2. WSRP – Web Services for Remote Portlets

3. WSIA

4. WS-Presentation

• Selected #2

• Change CSS prefix to “portlet-”