W3C

- DRAFT -

WS-Resource-Access WG F2F

14 Jan 2009

See also: IRC log

Attendees

Present
Bullen, Carpenter, Chou, Davis, Freund, Lafon, Li, Narayanaswamy, Malhotra, Mischkinsky, Pilz, Varma, Vedamuthu, Yendluri
Regrets
Chair
Bob Freund
Scribe
Doug Davis

Contents


<scribe> scribe: Doug Davis

<Bob> scribenick: Dug

f2f schedule revisited

Oracle confirmed for hosting Jun f2f

Sept - Katy/IBM - requested that we adjust the date

Suggests week of Sept 14th

hosted by IBM

in UK/Hursely

No objection - Sept F2F moved to week of Sept 14th in UK/Hursley hosted by IBM

lunch will be at 12:45-2pm pacific

<Yves> http://www.w3.org/Bugs/Public/buglist.cgi?product=WS-Resource%20Access

Issues

<gpilz> it seems to me that individual implementations could build against such a permissive schema

<gpilz> without us necessarily having to specify that schema in the standard

issue 6391 - accepted

assigned to Dug

issue 6392 - accepted - assigned to Dug

issues 6393-6395 - dup of 6392 - same issue, different operation

issue 6396 - accepted - assigned to Dug

issue 6397 - accepted - assigned to Gil

<gpilz> are there multiple bugzilla instances in the W3C?

http://www.w3.org/Bugs/Public/buglist.cgi?product=WS-Resource%20Access

issue 6398 - accepted - assigned to Dug

issue 6399 - accepted - assigned to Dug

issue 6400 - accepted - assigned to Dug

issue 6401 - accepted - assigned to Dug

issue 6402 - accepted - assigned to Dug

issue 6403 - accepted - assigned to Dug

issue 6404 - accepted - assigned to Dug

issue 6405 - accepted - assigned to Dug

issue 6406 - accepted - assigned to Dug

issue 6407 - accepted - assigned to Dug

issue 6408 - accepted - assigned to Dug

issue 6409 - accepted - assigned to Dug

issue 6410 - accepted - assigned to Dug

issue 6411 - accepted - assigned to Dug

issue 6412 - accepted - assigned to Dug

issue 6413 - accepted - assigned to Dug

issue 6414 - accepted - assigned to Dug

issue 6415 - accepted - assigned to Dug

issue 6416 - accepted - assigned to Dug

issue 6418 - accepted - assigned to Geoff

issue 6419 - dup of 6405

issue 6420 - dup of 6404

issue 6421 - accepted - assigned to Geoff

issue 6422 - accepted - assigned to Geoff

break until 10:45 pacific

issue 6424 - accepted - assign to Li

issue 6425 - accepted - assigned to Li

issue 6426 - accepted - assigned to Li

issue 6427 - accepted - assigned to Li

issue 6428 - accepted - assign to Li

issue 6429 - accepted - assigned to Li

issue 6430 - accepted - assigned to Li

issue 6431 - accepted - assigned to Li

<Yves> http://www.w3.org/Bugs/Public/buglist.cgi?product=WS-Resource%20Access

<asir> here is the uri if anyone needs it - mailto:public-ws-resource-access-notifications-request@w3.org?subject=subscribe

<Yves> http://lists.w3.org/Archives/Public/public-ws-resource-access-notifications/

issue 6432 - accepted - assigned to Gil

<Yves> Dug: http://www.w3.org/2003/Editors/

<Yves> http://lists.w3.org/Archives/Public/public-ws-resource-access-editors/

AI: Bob to provide info to editors on format of specs and on how to covert the docs.

issue 6391

<Yves> http://www.w3.org/2003/Editors/#grammars (for the xmlspec format)

gregc: should we allow impls to support both versions of WSA

?

gil: impls can do more than what's in the spec
... but we don't need to say that in the spec
... our schema should not be loosely typed

dug: make it a new issue.
... where do we stop? should we talk about WSA headers?

Wu: can a w3c spec refer to a non-standardized spec?

bob: it has happened - soap11 is the prime example
... ISO however doesn't like it
... personally, I would resist it

Wu: we should require normative reference - otherwise it could cause confusion

gregc: don't want a ref to old WSA - just wanted to know if we should allow the content model to be more open
... ok with this as long as I can open a new issue later to extend the model
... if I want

asir: some specs allow for both - we need a proposal to know how those will be dealt with

gil: our xsd/specs should not allow both
... replace xs:any with an EPR in those spots

<gregcarp> That's what I don't believe tehe current proposal endorses

<gregcarp> And I don' think I'm ready to agree to that

dug: we should replace xs:any with 2005 EPRs

<gregcarp> I am unwilling to make that call at this point

<gregcarp> I am not proposing a reference to the member submission

bob: 3 choices: 1) ref both, 2) xs:any->REC EPR, 3) REC EPR + extensibility

actually xs:any should be xs:any or any EPR reference

in option #2

<gregcarp> I agree with what Bob just said

bob: no one disagrees that REC must be 'in'
... extensibility points - how (and if) should they be worked into the spec?

Wu: extensibility points are optional

Gil: this is about schema design. Supporting both causes the use of an xs:any - its not just adding a ... after the REC EPR

bob: everyone agrees with that implication

gil: if this were just adding a ... but that's not what we're talking about - we're talking about having weakly typed EPRs - ie. xs:any's
... its harmful - we shouldn't do it.

jeff: should we stay silent on "other stuff"?

<Zakim> asir, you wanted to make a general observation

asir: schemas are generally weaker than the normative text

<gpilz> +1

<Ashok_Malhotra> +1

<gpilz> separate the issues

Dug: let's keep it simple for now - keep this issue about REC EPRs

bob: contentious point is about extensibility - having a hard time understanding how an xs:any can be used in a conformance clause

<gregcarp> simple to me means remove textual references to the submission version of addressing from the spec

<asir> but this issue is more than find and replace

its remove the option of other EPRs too

<asir> yes more than simple changes

bob: we all agree to support REC WSA - we need to discuss extensibility and form it takes
... some specs already have this and some do not
... for consistency they should all be the same
... can someone open an issue to discuss this issue

asir: this is more than just s/2004/2005/g

bob: suggests that since we're inconsistent across the specs - we need to either put them in everywhere or take then all out - but do that in a different issue
... for now suggest we leave any extensibility point there for now

asir: I want to see a concrete proposal

bob: I want to get thru more than one issue per day

asir: I see patterns

bob: make the directional decision but a red-lined version will be produced
... I'd like to get some kind of resolution
... any objection to this proposal?
... or to giving the editors editorial license to "do the obvious"

but leave xs:any->EPR issue out of it for now

resolution: Resolve Issue-6391 as proposed w/o

RT is included in the list of specs - group agrees

issue states: new, assigned, resolved, incorporated, closed

break for lunch - until 2pm pacific

<gregcarp> Zakim [Microsoft] is gregcarp

issue 6392

Dug: let's just match the text with the schema ;-)
... wsman profiles out multiple children too

<prasad-2> Will this work? ==> The presence of subsequent "embedded" child elements is service-specific and MAY be controlled by the presence or extension-specific SOAP headers in the original request

Ashok: spec is a subset of BP

dug: xsd and spec are inconsistent anyway

ashok: why not fix the schema?

dug: two ways to do it - change text or change xsd

geoff: don't want to remove a feature

gil: true but extensibility comes at a price
... interop trumps extensibility IMO

<gpilz> in this case at least

<gpilz> it would be a different matter if there were some clear and compelling use cases for extending the response

dug: perhaps we should have done the wrapper first

gregc: soap12 clearly allows multiple children in the body
... we don't view BP2.0 as a replacement for soap1.2

issue 6397

<Bob> 20 minutes cap

gil: remove the SubscriptionMgr EPR from the SubscriptionEnd message
... add text that talks about how you can use ref-params

Geoff: generally fine

Dug: as an editor - keep the stuff about ref-params?

<gpilz> Note, Subscribers wishing to correlate SubscriptionEnd messages with subscriptions may wish to add ReferenceParameters to the EndTo EPR.

<gpilz> (insert in description of EndTo EPR in section on Subscribe)

<scribe> ACTION: Gil to write up a more detailed proposal for 6397 [recorded in http://www.w3.org/2009/01/14-ws-ra-minutes.html#action01]

issue 6398

Dug: goes over the issue

Geoff: what about createResponse?

Dug: an oversight - that would be included

Geoff: unclear what impact this will have
... would like to see the impact on referenced specs

<gpilz> pretty clear we can't close anything without more detail

<gpilz> let's just recess for the rest of the afternoon so we can work on more detailed proposals

<prasad-2> ?

<Bob> ACTION: Dug to amplify proposal for 6398 correcting oversite of CreateResponse and to examine efect on RT, or other specs in-charter that reference Transfer as required. [recorded in http://www.w3.org/2009/01/14-ws-ra-minutes.html#action02]

<Yves> <Dug> Dug: we should have policy to describe all of the various options in the specs

<Yves> <Dug> Yves: what about the client sending in what it can support and the server choosing the best match?

Dug: define policy for each optional feature of the specs

Yves: why not let the client send in what it supports and let the server pick the best from that list?

Geoff: proposal says to define policy expressions - but it doesn't say 'how' to use them.
... wording around them about how to use them successfully.

Dug: examples? sure we can add those as needed.

gil: client sending in what it can support might not work - might not be scalable.
... examples: negotiation of policy is probably better left for a primer

<Yves> sending _everything_ supported by the client definitely won't fly, sending a shortlist of _preferred_ options (and let the server decide if it doesn;t match is much more practical

prasad: flat list of assertions or nested?

Dug: could be a combination - will probably depend on the specific feature

Asir: policy group wrote a best practices around this

<asir> 33 point check list at http://www.w3.org/TR/2007/NOTE-ws-policy-guidelines-20071112/

<asir> http://www.w3.org/TR/2007/NOTE-ws-policy-guidelines-20071112/#best-practices-list

wu: would like to understand the impact - would like a light-weight solution
... is policy optional?

Dug: yes - optional

gregc: security should be done by security policy

asir: while metadata is optional , if everyone uses it then its not so optional
... lean expressions is the key

Wu: would like to see some concrete examples

<scribe> ACTION: issue 6402 - Dug to write up a detailed proposal [recorded in http://www.w3.org/2009/01/14-ws-ra-minutes.html#action03]

issue 6404

Dug: proposal mex = everything you can and default == 'mex'

Asir: goes over the proposal from the workshop
... no dialect == up to provider
... mex dialect == all known dialects

<Ashok_Malhotra> Do you want to remove the 'whatever' option?

gregc: what if I'm a metadata browser

?

prasad: what does 'all metadata' mean?

dug: gimme everything I'm allowed to see
... I'd like to understand this 'whatever' option better

asir: not sure where the ambiguity is

ashok: dug is asking: what's it purpose? what does it do?
... tell us more about it? how? for what purpose?

<prasad-2> What metadata is visible to a client is subject to visibility constraints associated with the identity of the client and policy associated with the provider. We need to qualify *all* metadata (MEX) option to clarify that. That is the client may not be entitled to see all metadata even if the client asks for it.

Gil: can't think of an example of why someone would do this

<jacques> Just replace both "everything" and "whatever" with: "allyoucan"

<gregcarp> Is the 'r' silent in that "whatever", or not? :-)

<Ashok_Malhotra> whatevva!

<scribe> ACTION: issue 6404 - Geoff to write up why we need "whatever"? what's it purpose - and a new proposal [recorded in http://www.w3.org/2009/01/14-ws-ra-minutes.html#action04]

6397

Gil - talks about his concrete proposal

http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Jan/0038.html

resolution: new proposal accepted w/o

and they all rejoiced

<asir> Thanks Gil!

issue 6405

Dug: explained proposal

Jeff: need to define the skip

asir: 'format' might not be the best word for it

default == any, define an "all" dialect

(dialect (identifier)?)? (format)*

define a 'any' dialect

per jeff's comment, clarify that what 'skip' means - meaning no metadata section for that dialect/format

<gpilz> suggest synonyms for "format"; embodiment, incarnation

gregc: would policy help here?

dug: for advertising which are available,yes, but not for providing a hint

<gpilz> shape?

ai: issue 6405 - Doug to write up the above mods in a note/proposal

<gpilz> form?

<gregcarp> regarding the optimization

issue 6409

defer - people need to talk to devs

issue 6412

dug - describes the proposal

modification - make sure the PutModeNotSupported fault includes the uri

resolution: accepted w/o with the modification to the fault mentioned above

new issues

issue 6433 - accepted - assigned to Gil

issue 6435 - accepted - assigned to Gil

issue 6436 - accepted - assigned to Gil

issue 6408

dug describes the issue

geoff: could be a very large burden on the service

<Bob> meeting in recess until 2009-01-15 1300

Summary of Action Items

[NEW] ACTION: Dug to amplify proposal for 6398 correcting oversite of CreateResponse and to examine efect on RT, or other specs in-charter that reference Transfer as required. [recorded in http://www.w3.org/2009/01/14-ws-ra-minutes.html#action02]
[NEW] ACTION: Gil to write up a more detailed proposal for 6397 [recorded in http://www.w3.org/2009/01/14-ws-ra-minutes.html#action01]
[NEW] ACTION: issue 6402 - Dug to write up a detailed proposal [recorded in http://www.w3.org/2009/01/14-ws-ra-minutes.html#action03]
[NEW] ACTION: issue 6404 - Geoff to write up why we need "whatever"? what's it purpose - and a new proposal [recorded in http://www.w3.org/2009/01/14-ws-ra-minutes.html#action04]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.134 (CVS log)
$Date: 2008-11-14 12:03:15 $