[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [wsrp-wsia] Automatic resolve
20 | Resolved | interface | Technical | Gil Tayar | 22-Oct-2002 | Is entityState (a persistent state) necessary for v1? |
Date Added: | 4-Sep-2002 | |||||
Document Section: | Interfaces/11.5/EntityContext Type | |||||
Description: | - | |||||
Resolution: | Yes. It is required for Consumer-stored entity state | |||||
22 | Resolved | interface | Technical | Alan Kropp | 22-Oct-2002 | What is the rationale behind returning successfully released handles? |
Date Added: | 4-Sep-2002 | |||||
Document Section: | Interfaces/5.4 - releaseHandles | |||||
Description: | What is the rationale behind returning
successfully released handles? I believe the thinking is that the producer
can tell the consumer of any dependent entities that have been
released. But are there
actually any cases where the consumer doesn't know what the dependent
entities are? If not, it
seems like the method should instead throw an exception containing handles
that have _failed_ to be released. This seems like a more
straightforward way of letting the Consumer handle errors. Andre Kramer: I agree.] | |||||
Resolution: | releaseHandles was split into two operations, both which return either void or a fault | |||||
21 | Tentative Resolve | interface | Editorial | Rich Thompson | 31-Oct-2002 | More verbiage on why no release on initEnvironment |
Date Added: | 4-Sep-2002 | |||||
Document Section: | Interfaces/5.3 - initEnvironment | |||||
Description: | Need verbiage about why no release is needed, how timeout/need to reinitialize are signaled, etc. | |||||
Resolution: | Verbiage around usage of
initEnvironment() has been added: If the Producer's metadata has set the doInitEnvironment flag to true, then the Consumer MUST invoke initEnvironment() once for the groupID prior to invoking getMarkup() for this End-User for any entity using the same groupID. The Consumer MAY invoke initEnvironment() concurrently, each with a different groupID, for the interactions with the End-User. If at any time the Producer throws a fault message ("WSRP.Interface.InvalidEnvironment") indicating the environment for this groupID with this End-User has been invalidated at the Producer, then the Consumer MUST again invoke initEnvironment() for this groupID and SHOULD then reprocess the invocation that caused the fault message to be thrown. This fault message is in the table in section 14. That section briefly discusses that WSDL fault codes are strings with '.' delimited hierarchies for the messages. All of ours start with 'WSRP', currently there are two second level strings ('Security' and 'Interface'). | |||||
23 | Tentative Resolve | interface | Technical | Alejandro Abdelnur | 31-Oct-2002 | Adding clientParameters to getMarkup operation |
Date Added: | 4-Sep-2002 | |||||
Document Section: | Interfaces/6 - markup related/getMarkup | |||||
Description: | Add clientParameters to getMarkup? Could help when performInteraction() is not being used. | |||||
Resolution: | MarkupParams has this as a field named requestParameters in v0.8 | |||||
25 | Resolved | interface | Technical | Andre Kramer | 15-Oct-2002 | Could this be renamed markupRequest? Likewise for interactionContext |
Date Added: | 4-Sep-2002 | |||||
Document Section: | Interfaces/6 - markup related/getMarkup | |||||
Description: | Could this be renamed markupRequest? Likewise for interactionContext | |||||
Resolution: | These two structures have been renamed
MarkupParams and InteractionParams. | |||||
27 | Resolved | interface | Editorial | Rich Thompson | 15-Oct-2002 | Missing mapping of statefulness needs to the operations |
Date Added: | 4-Sep-2002 | |||||
Document Section: | Interfaces/6.2 - Stateful entity scenarios | |||||
Description: | well the mapping is missing, but the intent is here | |||||
Resolution: | Tables to provide the mapping for the
relevant data fields have been added. | |||||
28 | Resolved | interface | Technical | Alan Kropp | 15-Oct-2002 | CONFIG mode is optional under JSR-168 |
Date Added: | 4-Sep-2002 | |||||
Document Section: | Interfaces/6.3.4 - CONFIG mode | |||||
Description: | - | |||||
Resolution: | Description of CONFIG mode has been added. | |||||
29 | Resolved | interface | Technical | Alan Kropp | 15-Oct-2002 | DESIGN mode has no equivalent under JSR-168 |
Date Added: | 4-Sep-2002 | |||||
Document Section: | Interfaces/6.3.5 - DESIGN mode | |||||
Description: | - | |||||
Resolution: | DESIGN mode has been deleted ... could
not come up with a good description for it. | |||||
30 | Resolved | interface | Technical | Alan Kropp | 15-Oct-2002 | PREVIEW mode has no equivalent under JSR-168 |
Date Added: | 4-Sep-2002 | |||||
Document Section: | Interfaces/6.3.4 - PREVIEW mode | |||||
Description: | - | |||||
Resolution: | Description of PREVIEW mode has been added. | |||||
31 | Resolved | interface | Technical | Carsten Leue | 15-Oct-2002 | MINIMIZED state does not necessarily mean no markup |
Date Added: | 4-Sep-2002 | |||||
Document Section: | Interfaces/6.4.1 - MINIMIZED window state | |||||
Description: | Needed to modify this passage because in some circumstances the portlet might need to write into the output stream even if minimized. This is e.g. the case for Portlets rendering VoiceXML or for portlets that want to display some sort of status bar in minimized mode. | |||||
Resolution: | When the window state is
VIEW_MINIMIZED, the entity SHOULD render itself using minimal space. The entity SHOULD render no visible markup in this case, but is free to include non-visible data such as javascript or hidden forms. The Consumer MUST invoke the getMarkup() operation for the VIEW_MINIMIZED state just as for all other window states. The Consumer MAY render the title, controls and decorations related to the entity. I would note that Andre suggested that some Consumers may want to show a small image when the entity is minimized ... I would suggest that this not pollute these semantics, but that it would be a custom window state of the flavor 'Iconized'. | |||||
32 | Resolved | interface | Technical | Rich Thompson | 22-Oct-2002 | Do property operations need to be included in base? |
Date Added: | 4-Sep-2002 | |||||
Document Section: | Interfaces/Chapter 7 - introduction | |||||
Description: | The following need further discussion as to whether they are to be included in the base porttype of this specification | |||||
Resolution: | Yes. The F2F declared that persistent properties for entity configuration are to be included in v1.0. | |||||
33 | Resolved | interface | Technical | Andre Kramer | 15-Oct-2002 | propertyDescription structure missing from chapter 11 |
Date Added: | 4-Sep-2002 | |||||
Document Section: | Interfaces/Chapter 7 - getPropertyDescription | |||||
Description: | - | |||||
Resolution: | PropertyDescription is now section 6.1.10 | |||||
34 | Resolved | interface | Technical | Alejandro Abdelnur | 15-Oct-2002 | Do we want to define how an entity sends a title to the portal? |
Date Added: | 4-Sep-2002 | |||||
Document Section: | Interfaces/Chapter 9 - Introduction | |||||
Description: | - | |||||
Resolution: | Yes. We do. We added a "preferredTitle" field in the markupResponse. The resolution should wait until JSR168 syncs with this proposal (or rejects it!) | |||||
39 | Resolved | markup | Minor Editorial | Rich Thompson | 15-Oct-2002 | Does the example help to understand relationship between producer and consumer URL rewriting? |
Date Added: | 4-Sep-2002 | |||||
Document Section: | Interfaces/9.2.3 - relationship between consumer and producer writing | |||||
Description: | - | |||||
Resolution: | This portion was rewritten | |||||
40 | Resolved | markup | Minor Editorial | Andre Kramer | 15-Oct-2002 | Move URL Writing Semantics earlier |
Date Added: | 4-Sep-2002 | |||||
Document Section: | Interfaces/9.2.5 - URL Writing Semantis | |||||
Description: | - | |||||
Resolution: | Semantics regarding which party does the URL writing has moved into the intro section of the discussion. | |||||
44 | Resolved | interface | Technical | Gil Tayar | 15-Oct-2002 | Rename "expires" to "sessionExpires" in ResponseContext |
Date Added: | 4-Sep-2002 | |||||
Document Section: | Interfaces/11.6 - RequestTypes/ResponseContext | |||||
Description: | - | |||||
Resolution: | Structure and field have been renamed to reflect change to refHandle proposal | |||||
49 | Resolved | meta | Technical | Carsten Leue | 22-Oct-2002 | Problem in the the use of multiple description records that derive from each other |
Date Added: | 4-Sep-2002 | |||||
Document Section: | Interfaces/11.11 - Description Types/introduction | |||||
Description: | The getDescription method's signature returns a Description object. Normal Stubs that are generated on the basis of the WSRP WSDL will only serialize the Description part even if the underlying object is in fact a Service or EntityDescription. We need to merge all information or establish multiple getDescription signatures | |||||
Resolution: | getDescription was split into two functions. See all I#12 and I#13 | |||||
51 | Tentative Resolve | meta | Technical | Carsten Leue | 31-Oct-2002 | Define a naming schema how WSRP binding tModel are named |
Date Added: | 4-Sep-2002 | |||||
Document Section: | Interfaces/13.3 - finding services in UDDI | |||||
Description: | We should define a naming schema how WSRP binding tModel a named to allow an easy search. This schema could be a hierachic schema like: "wsrp.binding.soaprpc", "wsrp.binding.dime", "wsrp.binding.mime" | |||||
Resolution: | SPEC_VERSION_FACTOR_WSDLTYPE_TYPESPECIFIC Where: - SPEC = 'WSRP' - VERSION = v1 (this time) - FACTOR is one of 'Markup', 'ServiceDescription', 'Registration' or 'EntityManagement' (may yet get tweaked) - WSDLTYPE is one of 'PortType', 'Binding' or 'Service' - TYPESPECIFIC currently includes 'SOAP' | |||||
52 | Resolved | introduction | Editorial | Rich Thompson | 15-Oct-2002 | How should we organize use cases |
Date Added: | 4-Sep-2002 | |||||
Document Section: | Interfaces/Appendix A - Use cases/introduction | |||||
Description: | The following are WSRP use cases ... do
we want to name the appendix that and have a separate one for WSIA use
cases? Include subsections here for WSIA use cases? Other
options? Rich: Intention is to hyperlink to Use cases from the Introduction section. | |||||
Resolution: | hyperlink to Use cases from the Introduction section. | |||||
54 | Resolved | interface | Technical | Sasha Aickin | 22-Oct-2002 | WSRP session to consumer - end user session |
Date Added: | 10-Sep-2002 | |||||
Document Section: | ||||||
Description: | Shall we specify how WSAR sessions map
to consumer - end user sessions ? Proposal from Gil: Specify "WSRP session between consumer and producer maps to end user session of the consumer" - what end user session means depends on the consumer. | |||||
Resolution: | Gil's proposal was accepted | |||||
55 | Resolved | registration | Technical | ? | 22-Oct-2002 | Shall we have a registerConsumer operation in the 1.0 spec or out of band ? |
Date Added: | 10-Sep-2002 | |||||
Document Section: | ||||||
Description: | Shall we have an registerConsumer function in the specification ? Or shall we leave it as an out of band operation that we just assume to result in an opaque identifier ? In the latter case, releaseHandle on consumerRegistration handles would also go away. | |||||
Resolution: | While out of band is allowed, in band registration for v1.0 was decided to be included. | |||||
58 | entity mgmt | Technical | ? | 22-Oct-2002 | Should only POEs be published, only service or both | |
Date Added: | 10-Sep-2002 | |||||
Document Section: | ||||||
Description: | ||||||
Resolution: | Remove UDDI definitions from spec,
focus initial efforts on the information model that should be published to a directory for a Producer. | |||||
60 | Resolved | user info | Technical | Michael Freedman | 22-Oct-2002 | Presentation on WS-Security |
Date Added: | 10-Sep-2002 | |||||
Document Section: | ||||||
Description: | Its been proposed we rely on WS-security for carrying our user/role information. It would be useful to have a presentation that describes WS-security, what it covers, and how we can use it to solve our problems. We can then discuss the benefits/detractions ofrelying on it vs. defining some of our own concepts. | |||||
Resolution: | A presentation did in fact occur in the September F2F. | |||||
61 | Resolved | interface | Technical | Michael Freedman | 22-Oct-2002 | Interface Factoring |
Date Added: | 10-Sep-2002 | |||||
Document Section: | ||||||
Description: | We need to decide discuss how many interface factors we will define. We also need to discuss which one's will be required to be WSRP compliant. Fro example: If we decide that we define a service method to discover the interfaces supported by the service I would suggest this be separated from getDescription -- as its signature will have to be immutable across all [future] factors. Also, we need to understand if there will be "simpler" wsia factors and discuss whether they must be supported by WSRP consumers. Finally, we should discuss whether the WSRP required factor should only contain WSRP [1.0] function -- i.e. we have been discussing extended WSIA function [such as set transient props] that we may choose to put into an extended not required factor. Outside of the design issues above we also need to close the discussion on whether there are implementation details that affect factoring -- i.e. running multiple ports within the same session. | |||||
Resolution: | F2F decided to factor the interface using 4 factors. V0.7 reflects this factoring | |||||
62 | Resolved | entity mgmt | Technical | Michael Freedman | 22-Oct-2002 | Entity Management |
Date Added: | 10-Sep-2002 | |||||
Document Section: | ||||||
Description: | We still don't have a clear articulation of how entities are managed particularly when the management occurs across both the consumer and the producer. I.e. there is no clear definition of how a consumer controls the creation of a new entity when the producer provides the EDIT UI. Also, though we made the simplifying decision at the last F2F that we won't define hierarchical relationships between entities [such things would have to be maintained by the consumer], as Alan has pointed out previously, this is too restrictive. Basically, the architecture doesn't seem to support a hierarchical environment if both the consumer and producer are involved with managing entities [via the EDIT screen]. This seems way to restrictive and makes EDIT mode fairly useless. If this is the case we should toss the support or clarify how it can be used to solve these problems. | |||||
Resolution: | Process outlined in v0.7 based on September F2F decisions | |||||
64 | Resolved | customization | Technical | Michael Freedman | 22-Oct-2002 | Preference management negotiation |
Date Added: | ||||||
Document Section: | ||||||
Description: | We need to discuss what permutations we want to support for editing/storing entities [customizations]. I.e. Consumer UI + Consumer store, Consumer UI + producer store, Producer UI + Producer store, Producer UI + Consumer store. Do we support all or only some? What is the consumer required to support? What is the Producer required to support? If there is overlap, how does the negotiation get settled? | |||||
Resolution: | All permutations were approved.
Persistent state only produced by entity. In the case of Consumer UI gathering property updates, the setEntityProperties() sets the entity's state regardless of where it is stored. | |||||
65 | Resolved | interface | Technical | Michael Freedman | 22-Oct-2002 | JSR synchronization |
Date Added: | 10-Sep-2002 | |||||
Document Section: | ||||||
Description: | Maybe either Alejandro or Stefan Heper can prepare/give a presentation on where the JSR stands coming out of its F2F and more specifically, what is needed by WSRP to support the JSRs current semantics. Coming out of the JSR there is a need to pass more IDs to the portlet (portlet window ID). And there is a need to define that these IDs are invariant once they come into existence -- except for the group session ID which is invariant per lifetime of the session. We can also discuss whether the JSRs extensibility [mapping] should find its way into WSRP. There is also a need to discuss naming such as the names/prefix we use in the standard style sheet as JSR would like to leverage this. [Maybe we can use a generic prefix like: "fragment:"]. | |||||
Resolution: | A presentation was in fact...presented at the September F2F | |||||
68 | Tentative Resolve | interface | Technical | Carsten Leue | 31-Oct-2002 | Do we need initenvironment ? |
Date Added: | 10-Sep-2002 | |||||
Document Section: | ||||||
Description: | ||||||
Resolution: | Yes. It is needed. See I#18 | |||||
71 | Resolved | interface | Technical | Thomas Schaeck | 15-Oct-2002 | What's the difference between DESIGN MODE and CONFIG MODE ? |
Date Added: | 10-Sep-2002 | |||||
Document Section: | ||||||
Description: | ||||||
Resolution date: | ||||||
Resolution: | DESIGN mode has been deleted ... could
not come up with a good description for it. | |||||
72 | Resolved | markup | Technical | Carsten Leue | 15-Oct-2002 | Markup - Can Links directly point to getMarkup ? |
Date Added: | 10-Sep-2002 | |||||
Document Section: | ||||||
Description: | ||||||
Resolution: | Yes. See section 9.2.1.6.2 | |||||
73 | Resolved | interface | Editorial | Sasha Aickin | 15-Oct-2002 | userContext - optional or mandatory mixup in text |
Date Added: | 10-Sep-2002 | |||||
Document Section: | Interfaces/4 | |||||
Description: | In the description for userContext in getDescription, we say: "Since this operation does not receive any reference to a possible session, the userContext MUST be passed on each invocation." This sentence implies to me that the other arguments to getDescription are all optional (since they don't say that they MUST be passed), but I had sort of assumed that an argument was required unless specifically noted. Which is correct? | |||||
Resolution: | Rewritten as part of splitting getDescription() into 2 operations. | |||||
75 | Resolved | registration | Minor Technical | Sasha Aickin | 15-Oct-2002 | How to ensure consumerName is unique? |
Date Added: | 10-Sep-2002 | |||||
Document Section: | Interfaces/11.3 | |||||
Description: | For registrationData, section 11 says that consumerName should be globally unique. How do we want to suggest assigning a name in a globally unique way? | |||||
Resolution: | Draft v0.7 eliminates requirement statement, encourages uniqueness of the consumerName and suggests the Consumer's URL as such a name. | |||||
76 | Resolved | registration | Minor Technical | Sasha Aickin | 22-Oct-2002 | Why is the fact that Consumer supports transcoding surfaced in the spec? |
Date Added: | 10-Sep-2002 | |||||
Document Section: | Interfaces/11.3 | |||||
Description: | For registrationData, section 11 says that characterSetConversion indicates if the Consumer intends to convert character sets. Why is this surfaced in the spec? | |||||
Resolution: | characterSetConversion removed from meta-data | |||||
77 | Resolved | interface | Technical | Sasha Aickin | 22-Oct-2002 | specific semantics of sendPublishedState |
Date Added: | 10-Sep-2002 | |||||
Document Section: | ||||||
Description: | consumerContext's member sendPublishedState seems useful on some calls (like cloneEntity) but not on others (like registerConsumer). Further, the effects of the sendPublishedState flag are only explicitly described in the spec for cloneEntity and setProperties. I think we should describe what sendPublishedState does for each call, and we should probably take it out of the signatures of several of the methods. | |||||
Resolution: | sendPublishedState removed from meta-data | |||||
78 | Resolved | interface | Editorial | Sasha Aickin | 15-Oct-2002 | should we specify storage of consumerHandle? |
Date Added: | 10-Sep-2002 | |||||
Document Section: | Interfaces/5.1 - registerConsumer | |||||
Description: | In section 5.1, we say: "The Consumer SHOULD persistently
store the consumerContext. If the Consumer cannot persist the context, it
must attempt to release the consumerHandle using the releaseHandles()
method when exiting the current conversation." I think it makes more sense not to
try to commit to a notion of persistence on the Consumer but instead to
say: "The Consumer MUST use releaseHandles() on every consumerContext that
is returned as a result of registerConsumer()." This is the only requirement that
the spec cares about; from the spec's perspective it doesn't matter how
the consumer handle is stored.
Along the same lines, I think that the following text in the
description of cloneEntity: "The handle of the new
ConsumerConfiguredEntity must be persisted by the Consumer and released
when it is no longer needed. If the Consumer is unable to persist the
entity it must release it before the conversation ends." should be changed
to: "The handle of the new ConsumerConfiguredEntity MUST be released when
it is no longer needed." | |||||
Resolution: | Language was updated to eliminate
discussion concerning whether or not he Consumer persists handles to focus on releasing them at the end of their lifecycle management. Draft v0.7 incorporates the suggestion to remove language about different Consumer implementation choices. | |||||
79 | Resolved | interface | Technical | Sasha Aickin | 15-Oct-2002 | Why return consumerHandle in modifyConsumer's consumerContext? |
Date Added: | 10-Sep-2002 | |||||
Document Section: | Interfaces/5.1 | |||||
Description: | In section 5.1 in the description of modifyConsumer, we say: "A consumerContext is returned since the Producer MAY store state for this registration in this structure for the Consumer to supply on future invocations. The Producer MUST NOT modify the consumerHandle contained within this data structure." If the Producer MUST NOT modify the consumerHandle, then why are we even letting the Producer return a handle at all? If the only thing the Producer can change is the consumerState, I think that should be the only thing the operation returns. As it is, the operation's signature is confusing; I could easily see a Producer implementation mistakenly returning a new consumerHandle or a Consumer implementation mistakenly accepting a returned consumerHandle. | |||||
Resolution date: | ||||||
Resolution: | New structure (RegistrationCore) introduced to eliminate possibility of this error. | |||||
80 | Resolved | entity mgmt | Technical | Sasha Aickin | 15-Oct-2002 | cloneEntity and modification of properties - in same call? |
Date Added: | 10-Sep-2002 | |||||
Document Section: | Interfaces/5.2/cloneEntity | |||||
Description: | Why does cloneEntity take in an array of properties both in the entityContext argument and in the entityProperties argument? For that matter, why does cloneEntity allow the user to modify properties at all? Wouldn't it be simpler in the spec to just call cloneEntity and modifyEntity to achieve the same goal? | |||||
Resolution: | This optimization has been eliminated.
Draft v0.7 eliminates this piggybacked porperties parameter as per F2F decision. | |||||
83 | Resolved | interface | Minor Editorial | Sasha Aickin | 22-Oct-2002 | Is markupType a MIME type? |
Date Added: | 10-Sep-2002 | |||||
Document Section: | Interfaces/6.1 | |||||
Description: | Do we expect the markupType argument to getMarkup() to be a MIME type? If so, we should explicitly state that. | |||||
Resolution date: | 22-Oct-2002 | |||||
Resolution: | markupType MUST be a MIME type | |||||
84 | Tentative Resolve | interface | Minor Technical | Sasha Aickin | 31-Oct-2002 | More than a boolen in secureClientCommunication |
Date Added: | 10-Sep-2002 | |||||
Document Section: | Interfaces/6.1 | |||||
Description: | The argument secureClientCommunications
to getMarkup() seems to me to demand more than a boolean. It would be nice (with some sort
of extensible string) to indicate what level of security is being used
with the client, what kind of network is being used, etc. JSR168 defines (leveraging the Servlet specification) this 2 pieces of information. For authentication type defines 4 constants: BASIC, CLIENT_CERT, DIGEST and FORM, modeled after authentication mechanisms commonly used with HTTP. the isSecure attribute is a boolean indicating if the communication between the client and the consumer is secure or not (i.e.: HTTPS). Note that a client-consumer communication can be authenticated but not secure and vice versa. Also note that JSR168 explicitely says that this information s between the client (user agent) and the portal. | |||||
Resolution: | 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 Producer. | |||||
86 | Tentative Resolve | interface | Technical | Sasha Aickin | 31-Oct-2002 | Detailed definition of transportHeaders lacking |
Date Added: | 10-Sep-2002 | |||||
Document Section: | Interfaces/6.1 | |||||
Description: | The description of the transportHeaders argument to getMarkup is not as full as I would like. Specifically, I think it should mention: (1) if we means "last-hop" headers or "first-hop" headers. This becomes interesting in the case of a portal A re-serving portlets up as WSRP services to be consumed by portal B, which in turn is embedding them in a user's page. Should the transportHeaders argument have the headers from the first straight HTTP hop from the user to portal B or the HTTP (or SOAP?) headers in the hop from portal B to portal A? (2) should hop-by-hop HTTP headers be taken out? what about headers that could compromise the security of the serving portal (like Cookie or Authorization)? | |||||
Resolution: | requestMetadata', as the field is now called, is described as a combination of information either from the initial client transport layer or data stores the Consumer manages and is choosing to pass to the Producer. | |||||
87 | Resolved | interface | Minor Technical | Sasha Aickin | 22-Oct-2002 | Modes as navigation state vs. Modes as another state of the Entity |
Date Added: | 10-Sep-2002 | |||||
Document Section: | Interfaces/6.3 | |||||
Description: | I'm confused about the use of modes. As written right now, the Consumer passes the mode to the Producer on calls to getMarkup and performInteraction. I think the spec intends that a portlet is always considered to be in one of the possible modes, but I don't think that the Consumer can always know the mode. For example, say the user clicks "Edit" in the portal and the Consumer calls getMarkup with the EDIT mode. Now, the user clicks a link in the page. How does the Consumer know if the Producer transitions back to VIEW mode or not? It seems to me that we should think of things like EDIT and CONFIG as predefined resources that the Producer can serve up. There will be only one "page" each that corresponds to EDIT, CONFIG, PREVIEW, etc., and not all calls to getMarkup should have a mode. Does this make sense to folks? | |||||
Resolution: | It was decided in the September F2F
that Mode is a piece of state related to the Consumer's viewer, not the entity's state | |||||
88 | Resolved | markup | Minor Editorial | Sasha Aickin | 15-Oct-2002 | Producer URL Writing section is confusing |
Date Added: | 10-Sep-2002 | |||||
Document Section: | Interfaces/9 | |||||
Description: | I haven't followed the Markup Committee
very closely, and I found the section on both Producer & Consumer URL
Writing confusing. The
questions I have are: -- What is the exact syntax of a template for Producer URL Writing? I think it would be very useful to have a BNF grammar here to make sure that we all agree what the syntax is. Is the following a correct interpretation of the spec? WSIAProducerURLTemplate = (Text* ReplacementToken*)* Text = <any UNICODE character except '{' and '}'> ReplacementToken = '{' ParameterName '}' ParameterName = 'sessionID' | 'navigationalState' | 'clientParameters' | |||||
Resolution: | First pass at a BNF-like notation added | |||||
89 | Resolved | markup | Minor Editorial | Sasha Aickin | 15-Oct-2002 | Consumer URL Writing section is confusing |
Date Added: | 10-Sep-2002 | |||||
Document Section: | Interfaces/9 | |||||
Description: | -- Similarly, is the following a
correct BNF for Consumer URL Writing? WSIAConsumerURLTemplate = ConsumerURLBeginToken NameValuePairList ConsumerURLEndToken ConsumerURLBeginToken = 'wsia:QXqKYZJVUWj7G?' ConsumerURLEndToken = '/wsia:QXqKYZJVUWj7G' NameValuePairList = NameValuePair ('&' NameValuePair)* NameValuePair = NavigationalStateNameValuePair | SessionIDNameValuePair | EntityModeNameValuePair | WindowStateNameValuePair | URLNameValuePair | TokenNameValuePair | URLTypeNameValuePair | ConsumerResourceTypeNameValuePair SecureURLNameValuePair | RewriteResourceNameValuePair NavigationalStateNameValuePair = 'wsia:navigationalState' '=' Value SessionIDNameValuePair = 'wsia:sessionID' '=' Value EntityModeNameValuePair = 'wsia:entityMode' '=' EntityModeValue WindowStateNameValuePair = 'wsia:windowState' '=' WindowStateValue URLNameValuePair = 'wsia:url' '=' URI TokenNameValuePair = 'wsia:token' '=' Value URLTypeNameValuePair = 'wsia:urlType' '=' URLTypeValue ConsumerResourceTypeNameValuePair = 'wsia:consumerResourceType' '=' ConsumerResourceValue SecureURLNameValuePair = 'wsia:secureURL' '=' BooleanValue RewriteResourceNameValuePair= 'wsia:rewriteResource' '=' BooleanValue URLTypeValue = 'Action' | 'Render' | 'Resource' | 'Namespace' | 'ConsumerResource' EntityModeValue = 'EDIT' | 'VIEW' | 'CONFIG' | 'HELP' | 'PREVIEW' | Value WindowStateValue = 'MINIMIZED' | 'MAXIMIZED' | 'NORMAL' ConsumerResourceValue = 'OK_ICON' | 'OK_TEXT' | 'CANCEL_ICON' | 'CANCEL_TEXT' | 'INFO_ICON' | 'INFO_TEXT' | 'WARNING_ICON' | 'QUESTION_ICON' BooleanValue = 'true' | 'false' Value = <any text without substring '/wsia:QXqKYZJVUWj7G' or 'wsia:QXqKYZJVUWj7G?'> | |||||
Resolution: | First pass at a BNF-like notation added | |||||
90 | Tentative Resolve | interface | Minor Technical | Sasha Aickin | 7-Nov-2002 | When are Producer URL writing templates sent? |
Date Added: | 10-Sep-2002 | |||||
Document Section: | Interfaces/9 | |||||
Description: | Finally, exactly what parameters of
which calls in the interface are Producer URL writing templates sent
on? I think we should mention
that in the Consumer URL Writing section. | |||||
Resolution: | Section 9.2.2 of the v0.8 draft calls
out that these are passed on the getMarkup() invocation though we may consider an optimization may cause them be only sent once per session. | |||||
95 | Resolved | entity mgmt | Technical | Rich Thompson | 22-Oct-2002 | destroyEntities() & refHandles |
Date Added: | 19-Sep-2002 | |||||
Document Section: | Interfaces/5.2 | |||||
Description: | At the F2F we separated
releasedHandles() into 2 operations, one of which is destroyEntities(). We also began the exploration of what the signatures would look like with a unified refHandle that encode both entityHandle and sessionID. What semantics do we want to define for a refHandle being passed to destroyEntities()? What are the semantics for destroying entities that have active sessions on them? | |||||
Resolution: | Draft v0.7 does not allow refHandles to
be passed to destroyEntities() as the semantics are to destroy the persistent entity, not a runtime refinement of it. | |||||
98 | Tentative Resolve | customization | Minor Technical | Ravi Konuru | 31-Oct-2002 | Entity property customization and return values |
Date Added: | 23-Sep-2002 | |||||
Document Section: | Interfaces/7 - published state interfaces | |||||
Description: | Should methods return changed
properties (side-effects) ? E.g Should setProperties call on certain properties allowed to return properties and values more than those specified? | |||||
Resolution: | It was the consensus in the F2F that the answer is "No". | |||||
99 | Tentative Resolve | interface | Minor Technical | Ravi Konuru | 31-Oct-2002 | Entity property customization and user context |
Date Added: | 23-Sep-2002 | |||||
Document Section: | Interfaces/7 - published state interfaces | |||||
Description: | The current signature of setProperties
and getPropeties takes a usercontext as an argument implying that the properties returned by an entity may be dependent on the user. This in turn implies that an entity is potentially maintaining multiple property models, one per user. Such a concept seems to conflict with the notion that an entity exposes a single set of persistent properties for configuration. | |||||
Resolution: | Yes.There are multiple property models per user | |||||
103 | Resolved | interface | Minor Technical | Yossi Tamari | 16-Oct-2002 | In vendor extensibility "object any" should be an array |
20 22-Oct-2002 Is entityState (a persistent state) necessary for v1? 22 22-Oct-2002 What is the rationale behind returning successfully released handles? 25 15-Oct-2002 Could this be renamed markupRequest? Likewise for interactionContext 27 15-Oct-2002 Missing mapping of statefulness needs to the operations 28 15-Oct-2002 CONFIG mode is optional under JSR-168 29 15-Oct-2002 DESIGN mode has no equivalent under JSR-168 30 15-Oct-2002 PREVIEW mode has no equivalent under JSR-168 31 15-Oct-2002 MINIMIZED state does not necessarily mean no markup 32 22-Oct-2002 Do property operations need to be included in base? 33 15-Oct-2002 propertyDescription structure missing from chapter 11 34 15-Oct-2002 Do we want to define how an entity sends a title to the portal? 39 15-Oct-2002 Does the example help to understand relationship between producer and consumer URL rewriting? 40 15-Oct-2002 Move URL Writing Semantics earlier 44 15-Oct-2002 Rename "expires" to "sessionExpires" in ResponseContext 49 22-Oct-2002 Problem in the the use of multiple description records that derive from each other 52 15-Oct-2002 How should we organize use cases 54 22-Oct-2002 WSRP session to consumer – end user session 55 22-Oct-2002 Shall we have a registerConsumer operation in the 1.0 spec or out of band ? 60 22-Oct-2002 Presentation on WS-Security 61 22-Oct-2002 Interface Factoring 62 22-Oct-2002 Entity Management 64 22-Oct-2002 Preference management negotiation 65 22-Oct-2002 JSR synchronization 71 15-Oct-2002 What's the difference between DESIGN MODE and CONFIG MODE ? 72 15-Oct-2002 Markup - Can Links directly point to getMarkup ? 73 15-Oct-2002 userContext - optional or mandatory mixup in text 75 15-Oct-2002 How to ensure consumerName is unique? 76 22-Oct-2002 Why is the fact that Consumer supports transcoding surfaced in the spec? 77 22-Oct-2002 specific semantics of sendPublishedState 78 15-Oct-2002 should we specify storage of consumerHandle? 79 15-Oct-2002 Why return consumerHandle in modifyConsumer's consumerContext? 80 15-Oct-2002 cloneEntity and modification of properties - in same call? 83 22-Oct-2002 Is markupType a MIME type? 87 22-Oct-2002 Modes as navigation state vs. Modes as another state of the Entity 88 15-Oct-2002 Producer URL Writing section is confusing 89 15-Oct-2002 Consumer URL Writing section is confusing 95 22-Oct-2002 destroyEntities() & refHandles 103 16-Oct-2002 In vendor extensibility "object any" should be an array
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC