OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsia message

[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