OASIS Web Services for Remote Portals (WSRP) TC

WSRP/WSIA Telecon 10/10/02

Roll

Alan was late to the meeting, roll was taken by Thomas.

Charlie took minutes for most of the review of tentative resolutions.

Review Tentative Resolutions

8: BTP two-phase process, seems not to map to our protocol, but suggest to call our process a two-step rather than phase to avoid confusion with two phase transaction protocol
no objection

34: adding preferred title field to markup response
mike: please motivate diff from jsr?
rich: f2f discussion was to provide simple field in markup response or statically declared in entity metadata
mike: don't mark resolved, consider sync with jsr
rich: what would that be?
mike: jsr allows for resources on titles in addition to string, for non-string based titles - for alternative device support, extended resources
alej: resources are always strings
mike: wsrp allows only one string though, propose we keep open pending response to note on deviance between jsr and wsrp, perhaps discuss all of these next week
rich: concerned with getting full list onto email to be resolve next week
thomas: will follow up with alejandro to go through list and see if appropriate/when to post to wsrp list
mike: jsr is trying to lock down their spec, may have to make decisions in advance of wsrp
thomas: have call asap, discuss these on wsrp call next week -- keep 34 open until next week

35: recommended strong enough language for non-ascii encoding in 9.2 for URL? in f2f URL needed UTF-8 so should become a MUST
mike: need details of discussion, seems to go against current dev practices in web apps - has sent emails for clarification...would like to explore question of whether f2f decision is correct
rich: let's leave open until the 17th, 0.7 spec recommends following standard URL encoding conventions, hence stronger than recommend..if others can respond to mike that would be good
mike: will send questions to others as well
sasha: volunteers to help as well

36: no objection

41: consensus is no...not all CSS classes mode dependent
mike: what's the orginal question?
rich: when CSS classes put together by markup group, had mode dependent character, decision was to remove those since consumer can use different CSS depending on mode

50: metadata for service descrption and service description as explicit element type in wsdl? f2f was no - in wsrp structures only

Mike F: Leave #57 open

Properties

Charlie leading discussion.

Currently in 0.7 draft (some minor changes not yet reflected).

Axis and .NET seem to be ok with the metadata.

Alejandro: How about restricting to string-values, no schema? There is no requirement in the JSR to do validation based on meta-data.

Charlie: To support sub-range checking, other useful restrictions, it would be nice to have schema. Also, thought it was a requirement in the JSR to do certain validation.

Mike F: There's no hard requirement to do validation in the JSR.
Nothing preventing it either.

Property Description Metadata

Persistent entity properties.

Takes an entity handle directly (not refHandle), registration context, entity context, user context

Fair amount of discussion around user context is "admin"?

Return property description, optional schema for user-defined data types.

Thomas: Labels need to be internationalized?

Charlie: Slippery slope...really want a property description language, not a new markup. Come back to this.

Stephen Smith: Element with UTF label and hint for different languages?

Bruce: Still doesn't address how to describe different languages, etc.

Thomas: So it's still a slippery slope. Return desired locale in property description, or return all possible locales?

Charlie: So we should continue to work out the details for i18n.

Getter

Still takes entityHandle, etc.

Property list container element.

Carsten: Can property name contain a wildcard?

Charlie: No. Taking a simple cut for the 1.0 spec.

Rich: Explicit listing of properties, or leave it empty (null?) for entire property set.

Setter

Same as above, list is now name-values.

Distinguish setting to null from setting to a default value. Boolean flag to indicate.

Mike F: Have you tested this null/reset scheme with the stacks?

Charlie: Not yet, but will follow up.

Mike F: Why setProperty returns interactionResponse?

Rich: Since this is the programmatic interface for user interaction, it could be useful to allow for interaction context.

Mike F: Is this a bit awkward? It also seems that we haven't fully defined the semantics of property management with respect to entity lifecycle.

Charlie: We can continue to refine this.

Mike F: If it's going to return interactionContext, then the implied semantic is that it's a blocking call.

Thomas: To summarize the main issue, can setting a property have a similar side-effect issue that requires a blocking call?

Mike F: Yes, this is what needs further clarification.

Caching

Rich: Introduce validation key? Sense from email discussion is that people want this?

Sasha: Essentially eTags, right? (numerous answers: yes, almost).

Carsten: Put the original proposal into the spec, and don't understand what the validation key provides?

Sasha: Seems very complicated for the Producer to keep track of all of the cached content?

Yossi: The Producer could simply choose to invalidate all pages for a user.

Carsten: The Consumer should have all the information it needs about the content, and what should/should not be cached.

Mike F: But that's entirely Consumer-side. This could be a cache between the Producer/Consumer.

Sasha: Expires and eTag caching give consistent results, whether Consumer uses it or not. But you can't ignore invalidation-based mechanism, because you'll get inconsistent results.

[lengthy discussion ensued regarding whether the Consumer has enough information to do fine-grained cache mgmt on its own (Sasha), vs. view that the Consumer definitely does not have this information since entity state management is Producer-side and opaque in most cases (Mike)]

Carsten: My proposal is intended to address Consumer-side cache management, whereas Yossi's proposal addresses Producer-mediated control over caching. Not sure why such mediation would be necessary.

Mike F: I put out a response to Yossi's initial email that laid out the specifics.

Carsten: I'll look for it.