Presentation is loading. Please wait.

Presentation is loading. Please wait.

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.

Similar presentations


Presentation on theme: "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."— Presentation transcript:

1 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

2 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

3 #133 - extensions typing JSR168 uses String and String[] as the only extension types WSRP uses 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. oCorrelated: #93 – Payload extensibility mechanism v0.7 changed from typed Property[] to introduce 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. oCorrelated: #121 - user-info extensions being

4 #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.

5 #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

6 #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.

7 #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

8 #119 - Portlet Mode and Window State constants, name change JSR168 does not include the redundant _MODE and VIEW_ portions of WSRP names oCorrelated: #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

9 #115(2nd) – CSS prefix Proposed resolution: change “ wsia- ” to “ markup- ” –Resolved: portlet – (5) fragment – (13) markup - markup-fragment – 11 (2) abstain – 11 (2)

10 #152 - F ormat 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

11 Pending resolutions 19 - Verbiage around usage of initEnvironment() added MarkupParams has requestParameters in v 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 Draft v0.81 (small grammar update) describes an entityHandle in section 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 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

12 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

13 #6 - Is groupId required? Current draft: oEntityDescription contains a groupID oProducerDescription contains a flag called doInitEnvironment oIf doInitEnvironment= ’ true ’, the Consumer MUST invoke initEnvironment once per groupID per user session as the Consumer defines it oinitEnvironment says what groupID it is for oConsumer MAY be required to manage cookies (Producer flag) Do we want a protocol level field for non-cookie use? –no oIf an operation faults with InvalidEnvironment, Consumer MUST reinvoke initEnvironment(). oResolved: Drop groupID from initEnvironment. No groupID => in “” group

14 #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

15 #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

16 #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 “ …

17 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

18 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).

19 #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

20 Impacts Consumer managing persistent state Doesn’t impact Consumer managing persistent state Impacts other entities Current performInteraction Doesn’t impact other entities Proposed non- blocking actions Current getMarkup

21 #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

22 #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 URIs 4. No stated limit. Add Producer metadata declaring limit the Producer implements. Resolved: #1

23 #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

24 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

25 #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.

26 #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

27 #91 Is setEntityProperties atomic? Customization subgroup decided it should be atomic. –Validated and synchronized update, but not required to be transactional.

28 #120 - PropertiesDescription not in entityDescription, why? Will enough Consumers want this information to place it in EntityDescription? –no

29 #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

30 #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.

31 #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.

32 #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

33 #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.

34 #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’

35 #37 & 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.

36 #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?

37 #114 - Should custom roles, modes & window states use namespacing? URIs are encouraged in current draft. Resolved: don’t bother

38 #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

39 #48 - Should an entity say that it is cloneable? Sept F2F said “ No ” … Producer level and indicated by exposure of EntityManagement portType –Resolved: no

40 Pending resolutions Add releaseRefHandles(refHandle[], registrationContext) to the Markup portType. – resolved: add it for now 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]

41 #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).

42 #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.”

43 #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[]

44 #130 - minimial encoding of Url rewriting params Examples should encode only ‘&’, ‘=’, ‘?’, and ‘/’. –Check for ‘:’ …

45 #101 - Valid values for MarkupParams fields Are the v0.8 draft references/examples acceptable? Specific additions/subtractions? – specific changes to Rich

46 #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

47 #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?)

48 #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 ….

49 #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.

50 #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

51 #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

52 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

53 #140 Internationalization of property and entity descriptions Short entity title OR Short entity title Separate resource contains: English text French text 1. Inline: Separated: 3 Abstain: 2 Indirect through resources? Yes: 12 No: 7 Abstain: 4

54 #140 Internationalization of property and entity descriptions Example use for property descriptions is:

55 #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

56 #100 - Entity property representation, serialization, and extensibility Proposed property description from the 0.8 draft. Property ’ s value Define this coupling for localized attributes Property 1 Perhaps a tooltip Use this format for PropertyDescription Capitalize as per rest of structures

57 #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);

58 #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

59 #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)

60 #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)

61 #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. ”[A206] -Replace italized text with description of what happens when a refHandle is not returned and what a Consumer SHOULD do when dropping a refHandle.

62 #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).

63 #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

64 #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);

65 #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 #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);

67 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

68 #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

69 #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?

70 ed 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? - no o GetMarkupIsIdempotent? - no o MustBeCloned? - no o ? What will the xxxx in xxxx- be? (have wsrp & wsia placeholders in various places now)

71 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-”


Download ppt "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."

Similar presentations


Ads by Google