[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [wsia] 10-10 Minutes for Website
Hi Folks, This Post is just for the purpose of ease in getting the minutes onto the website. 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. -- Rex Brooks Starbourne Communications Design 1361-A Addison, Berkeley, CA 94702 *510-849-2309 http://www.starbourne.com * rexb@starbourne.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC