|
|
|
|
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 |
|
|
|
|
|
Thursday AM |
|
102 |
|
111 |
|
118 |
|
129 |
|
Thursday PM |
|
59 |
|
130 |
|
105, 115 |
|
66 |
|
101 |
|
117 |
|
139 |
|
|
|
|
|
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. |
|
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. |
|
Correlated: #121 - user-info extensions being
<any> |
|
|
|
|
|
|
|
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. |
|
|
|
|
|
|
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 |
|
|
|
|
|
|
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. |
|
|
|
|
|
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 |
|
|
|
|
|
|
JSR168 does not include the redundant _MODE and
VIEW_ portions of WSRP names |
|
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 |
|
|
|
|
|
|
|
|
Proposed resolution:
change “wsia-” to “markup-” |
|
Resolved: |
|
portlet – 11111 (5) |
|
fragment – 1111111111111 (13) |
|
markup - |
|
markup-fragment – 11 (2) |
|
abstain – 11 (2) |
|
|
|
|
|
|
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 |
|
|
|
|
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 |
|
|
|
|
|
|
|
Current draft: |
|
EntityDescription contains a groupID |
|
ProducerDescription contains a flag called
doInitEnvironment |
|
If doInitEnvironment=’true’, the Consumer MUST
invoke initEnvironment once per groupID per user session as the Consumer
defines it |
|
initEnvironment says what groupID it is for |
|
Consumer MAY be required to manage cookies
(Producer flag) |
|
Do we want a protocol level field for non-cookie
use? |
|
no |
|
If an operation faults with InvalidEnvironment,
Consumer MUST reinvoke initEnvironment(). |
|
Resolved: Drop groupID from initEnvironment. No
groupID => in “” group |
|
|
|
|
depends on entity metadata |
|
|
|
|
|
|
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 |
|
|
|
|
|
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“ … |
|
|
|
|
|
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 |
|
|
|
|
|
|
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). |
|
|
|
|
|
|
|
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 |
|
|
|
|
|
|
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 |
|
|
|
|
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 |
|
|
|
|
|
|
|
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 |
|
|
|
|
|
|
|
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. |
|
|
|
|
|
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 |
|
|
|
|
|
Customization subgroup decided it should be
atomic. |
|
Validated and synchronized update, but not
required to be transactional. |
|
|
|
|
|
|
|
Will enough Consumers want this information to
place it in EntityDescription? |
|
no |
|
|
|
|
|
|
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 |
|
|
|
|
|
|
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. |
|
|
|
|
|
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. |
|
|
|
|
|
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 |
|
|
|
|
|
|
|
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. |
|
|
|
|
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’ |
|
|
|
|
|
|
Switch to xxxx- or stay with xxxx:? |
|
What will xxxx be? (planned for Friday
discussion) |
|
|
|
Resolved, use ‘xxxx-’ instead. |
|
|
|
|
|
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? |
|
|
|
|
|
|
URIs are encouraged in current draft. |
|
|
|
Resolved:
don’t bother |
|
|
|
|
|
|
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 |
|
|
|
|
|
Sept F2F said “No” … Producer level and
indicated by exposure of EntityManagement portType |
|
|
|
Resolved:
no |
|
|
|
|
|
|
|
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] |
|
|
|
|
|
|
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). |
|
|
|
|
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.” |
|
|
|
|
|
Does this want to include a means to locate a
type for the extensions? |
|
|
|
Resolved:
Leave as String[] |
|
|
|
|
|
Examples should encode only ‘&’, ‘=’, ‘?’,
and ‘/’. |
|
|
|
Check for ‘:’ … |
|
|
|
|
|
Are the v0.8 draft references/examples
acceptable? Specific additions/subtractions? |
|
|
|
Email specific changes to Rich |
|
|
|
|
|
ServiceDescription is the other required
interface and logically is used before the markup interface. |
|
Current order: |
|
ServiceDescription |
|
Markup |
|
Registration |
|
EntityManagement |
|
|
|
Resolved:
Keep order |
|
|
|
|
|
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?) |
|
|
|
|
|
|
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
…. |
|
|
|
|
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. |
|
|
|
|
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 |
|
|
|
|
|
|
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 |
|
|
|
|
|
|
<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> |
|
|
|
|
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> |
|
|
|
|
|
|
Why localize the values? |
|
Resolved:
don’t |
|
|
|
|
|
|
|
|
|
In the get____Description operations. |
|
Resolved: Operations take both a
desiredLocales[] and sendAllLocales flag |
|
|
|
|
|
|
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> |
|
|
|
|
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); |
|
|
|
|
|
|
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 |
|
|
|
|
|
|
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) |
|
|
|
|
|
|
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) |
|
|
|
|
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. |
|
|
|
|
|
|
Must attempt language appears to have gotten
removed (was not intentional :} ). For both deregister and destroyEntities,
do we want: |
|
|
|
“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. |
|
|
|
For destroyEntities, use fault or create a
return type to carry an array of failures (failedHandle, faultCode,
extensions). |
|
|
|
|
|
|
|
|
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 |
|
|
|
|
|
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); |
|
|
|
|
|
|
|
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[]); |
|
|
|
|
|
EntityManagement portType (cont.) |
|
entityResponse =
setEntityProperties(registrationContext, entityContext,
userContext, propertyList); |
|
propertyList =
getEntityProperties(registrationContext, entityContext,
userContext, names); |
|
modelDescription = getEntityPropertyDescription(
registrationContext, entityContext,
userContext, desiredLocales[],
sendAllLocales); |
|
|
|
|
|
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 |
|
|
|
|
|
Desire expressed to have WebCollage publish
licensing terms. |
|
Waiting on WebCollage response |
|
IBM?? – likely to be similar to ebXML CPPA |
|
|
|
|
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? |
|
|
|
|
|
|
|
|
|
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? |
|
JSR168? - no |
|
GetMarkupIsIdempotent? - no |
|
MustBeCloned? - no |
|
? |
|
What will the xxxx in xxxx- be? (have wsrp &
wsia placeholders in various places now) |
|
|
|
|
|
|
|
|
WSRP – Web Services for Remote Portals |
|
WSRP – Web Services for Remote Portlets |
|
WSIA |
|
WS-Presentation |
|
|
|
Selected #2 |
|
|
|
Change CSS prefix to “portlet-” |
|