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