See also: IRC log
<scribe> scribe: Doug Davis
<Bob> scribenick: Dug
Oracle confirmed for hosting Jun f2f
Sept - Katy/IBM - requested that we adjust the date
Suggests week of Sept 14th
hosted by IBM
No objection - Sept F2F moved to week of Sept 14th in UK/Hursley hosted by IBM
lunch will be at 12:45-2pm pacific
<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?
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
<asir> here is the uri if anyone needs it - mailto:firstname.lastname@example.org?subject=subscribe
issue 6432 - accepted - assigned to Gil
<Yves> Dug: http://www.w3.org/2003/Editors/
AI: Bob to provide info to editors on format of specs and on how to covert the docs.
<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> 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
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
<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]
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
<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/
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]
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? :-)
<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]
Gil - talks about his concrete proposal
resolution: new proposal accepted w/o
and they all rejoiced
<asir> Thanks Gil!
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
ai: issue 6405 - Doug to write up the above mods in a note/proposal
<gregcarp> regarding the optimization
defer - people need to talk to devs
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
issue 6433 - accepted - assigned to Gil
issue 6435 - accepted - assigned to Gil
issue 6436 - accepted - assigned to Gil
dug describes the issue
geoff: could be a very large burden on the service
<Bob> meeting in recess until 2009-01-15 1300