WSRP/WSIA Telecon 10/10/02

Roll

Voting Members

Company

 

Stephen Drye

Art Technology Group

 

William Cox

BEA

Y

Adrian Fletcher

BEA

 

Gino Filicetti

Bowstreet

Y

Andre Kramer

Citrix

 

Timothy N. Jones

CrossWeave

Y

Peter J. Quintas

Divine

 

Alan Kropp

Epicentric

Y

Nigel Ratcliffe

Factiva

Y

Madoka Mitsuoka

Fujitsu

Y

Carsten Leue

IBM

Y

Thomas Schaeck, chair

IBM

Y

Rich Thompson

IBM

Y

Charles Wiecha

IBM

Y

Eric van Lydegraf

Kinzan

 

Joe Klein

Reed-Elsivier

Y

Adam Nolen

Reed-Elsivier

Y

Petr Palas

Moravia IT

Y

Mark Cassidy

Netegrity

Y

Olin Atkinson

Novell

 

Chris Braun

Novell

 

T.J. Cox

Novell

Y

Michael Freedman

Oracle

Y

Mike Hillerman

Peoplesoft

 

Andrew Sweet

Perficient

 

Sasha Aickin

Plumtree

Y

Jane Dynin

Plumtree

Y

Joseph Stanko

Plumtree

Y

Michael Yound

Plumtree

Y

Yossi Tamari

SAP Portals

Y

Brian Dirking

Stellent

 

Alejandro Abdelnur

Sun

Y

Dave Clegg

Sybase

 

Joe Rudnicki

U.S. Navy

Y

Eilon Reshef

WebCollage

Y

Gil Tayar

WebCollage

Y

Prospective Members (non-voting)

 

 

Gennady Shumaker

 

Y

Rex Brooks

 

Y

Richard Cieply

IBM

Y

Steven Smith

 

Y

Art Machado

 

 

Ken Pugsley

 

 

Raj Ramesh

 

 

Amir Blich

 

Y

Monica Martin

Drake Certivo

Y

WSIA Members

(non-voting)

 

 

Bruce Lucas

IBM

Y

Graeme Riddell

Bowstreet

 

 

 

 

 

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.