Web Services Resource Access Working Group Teleconference -- 10 Mar 2009

<trackbot> Date: 10 March 2009

<dug> anyone else on the line?

<dug> we dialed in

<dug> who is 908?

<dug> is anyone on the phone?

<dug> yves?

<Yves> I'm on the phone yes

<li> hi dug, 908 is li li

<dug> yves can you hear us on the phone?

<Bob> meeting: W3 WS-Resource Access Working Group

<Bob> scribe: Sreedhara

<Bob> scribe: Tom Rutt

<Bob> scribenick: TRutt

IRC admin

Bob asked members to watch IRC as it is happening, and if it does not match what they think it should be stating, they should make real time additions/corrections into the irc chat area themselves.

timing of issue discussions

Bob stated that he would allow a one week postponement of a scheduled vote if any member requests an extra week to consider an issue before the vote.

Asir: In our opiniion. Geoff was not given sufficient time to present his full proposal.

Minutes of prior meetings

<Bob> Minutes of 2009-02-24 http://www.w3.org/2002/ws/ra/9/02/2009-02-24.html

<Geoff> http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Mar/0027.html

Comments made by Geoff relative to edited version of minutes as posted.

Bob: could Geoff express which of his concerns were not reflected in the edited minutes

<li> msg wu hi

Geoff: We believe that the statement "Will more discussion help the decision?" shuld have been stated "Will more discussion of Geoff's proposal help the decision?"

The group reviewed the minutes and several members stated that the context at that point in the discussion was regarding both contributions.

The minutes were accepted by the working group with Geoff Bullen registering his objection in the email referenced above.

<asir> Not several members .. just two members

Minutes March 3,2009

<asir> stated that the context ...

<Bob> http://www.w3.org/2002/ws/ra/9/03/2009-03-03.html

<gpilz> make that 3 (me)

<dug> 4 - ibm too

No objections to approval of March 3 minutes

Revised agenda

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

Agreed to add three new issues which have arrived since the preparation of the agenda.

<Geoff> +q

Bob summarized the agenda, and asked if there were any requested changes.

<Bob> ach geo

Geoff: what about discussions regarding the TAG? We would like that discussion to be in the first two days.

Bob: lets spend a fair amount of first day on eventing, then move on if not completed on the second day
... after first day will try to spend some time on each of the issues.
... on the third day we can focus on the general discussion items.

TAG discussion agreed to be after lunch first day

Agenda, as modified was accepted by the group.

WG Administrivia

adding a f2f at the W3C Tech Plenary 2-6 November in Santa Clara; Potential WG meeting 11/2, 3, 5, and 6 (Must respond by March 18)

Yves: this gives us an opportunity to meet with the TAG, if we and they want to do so

No objection to having WG meetings at TPAC in November.

Discussion ensued on how may days of meeting are appropriate for the WG.

Agreed that Bob will ask for Two adjacent days for WG meetings at the TPAC in November

New Issues

Question on action items review.

Bob: I closed all action items which are completed, I suggest all members go thru the open action item list and work to close the ones assigned to themselves.

-Issue-6648 Eventing: define extensibility model for WS-Eventing http://www.w3.org/Bugs/Public/show_bug.cgi?id=6648 -Pilz

Gill agreed to be the Issue owner. No objection to opening this new issue

ID 6661

<Bob> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6661

No objection to opening issue 6661 with Gil as owner.

Id 6666

http://www.w3.org/Bugs/Public/show_bug.cgi?id=6666

No objection to open issue 6666 with Dug as owner.

<Bob> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6661

<Bob> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6672

No objections to open issue 6672 with Dug as owner

http://www.w3.org/Bugs/Public/show_bug.cgi?id=6673

No objections to open issue 6673 with Dug as owner

id 6674

http://www.w3.org/Bugs/Public/show_bug.cgi?id=6674

There is a general issue on updating references.

Agreed that 6674 is a duplicate of the existing general 'review references' issue

Geoff: that is 6570

id 6675

http://www.w3.org/Bugs/Public/show_bug.cgi?id=6675

No objection to open issue 6675 with Gil as owner

id 6674

Id 6676

http://www.w3.org/Bugs/Public/show_bug.cgi?id=6676

No objection to open 6676 with Gil as owner.

Issues with proposals

Issue 6424

<Bob> proposal at http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Mar/0026.html

Wu presented his latest email

Gil: I do not understand the addition of the wsa:To header to the subscription request

<dug> every time I see 'ack ...' I keep thinking of Bill the cat

Gil: if wsa:To is not present, is the event source given value anonymous?

Wu: yes

Gil: None of this is explained in the text

Wu: we state "The REQUIRED [event source] property provides the value of the WS-Addressing

wsa: To element.

<dug> perhaps a rewording of that line would help?

Gil: is the event source from the point of view of subsriber of the event source?

<dug> The [event source] property provides the value of the OPTIONAL WS-Addressing wsa:To element.

Wu: from the view of a subscription message from subscriber to event source.

<Yves> http://www.w3.org/TR/soap12-part1/#soapenvelope

<Yves> infoset constructs are not hard to read

<dug> Yves - personally I think infoset hurt wsa and soap specs :-)

<Yves> dug; infoset allows things like MTOM and use of other encodings of the envelipe

Asir: we could accept Wu's proposal, with understanding that additional issues can be raised to clarify specific text later

<dug> I understand why they were added - but I think they hurt more than they helped.

<dug> The [event source] property provides the value of the OPTIONAL WS-Addressing wsa:To element.

<asir> I believe that Wu's proposal is a template for global changes

Gil: I like this new wording

<dug> The REQUIRED [event source] property provides the value of the OPTIONAL WS-Addressing wsa:To element.

Wu: this new wording is acceptable, however we have to be careful on cardinality

<gpilz> The wsa:To element is populated by the REQUIRED [event source] property.

Wu: I prefer "provided" to populated

<gpilz> The value of the wsa:To element is provided by the REQUIRED [event source] property.

Dug: maybe we should map the ws eventing infoset to the appropriate ws addresssing infoset
... however Event source property would need to get mapped to destination plus reference properties

<dug> The value of the WS-Addressing [destination] and [ref params] properties is provided by the REQUIRED [event source] property.

Darecussion on the event source as an EPR vs an IRI

gil: however wsa:To is just a uri, but the event source EPR also can include ref parms

<gpilz> gil: and metadata

<Wu> wu

Gil: could have general discussion on ws addressing addressing properties, but don not have text describin the wsa headers. Only discuss wse headers in the text

<Bob> The values of the WS-Addressing [destination] and [ref params] properties are provided by the REQUIRED [event source] property.

replace from /s:Envelope/s:Header/wsa:To The REQUIRED [event source] property provides the value of the WS-Addressing wsa:To element.

<li> +q

Geoff: what about the wsa:Action text in this section

<dug> Geoff - that might be handled by the new issue I opened the other day

Bob: lets first discuss the replacement of the wsa:To line

DaveS: there is no way to reconstrict event source EPR from the headers in the subscribe message
... leave this text out say "ws addressing shall populate its headers as appropriate from the information in the event source epr"

<Bob> +1 , Li

Li: section 3.3 of ws addressing core text should not be repeated

<Zakim> asir, you wanted to point out symmetry

Li: put reference to ws addressing text

<dug> The [event source] is used as the target endpoint reference of the Subscribe message and is processed per WS-Addressing.

<DaveS> +1 to dug's text

Wu: I like Bob's text change for wsa:To, but suggest we keep the text on wsa:Action

<asir> Dug - alternate to what?

Dug: I intend my new text to replace the wsa:To line in the proposal

Gil: given Action value is a constant for this operation type, why does it need to be mapped to an infoset property?

Wu: infoset properties can be constants, there is no restriction against them having constant value

<dug> its too bad that someone didn't just write an XML->Infoset converter/rules and then we could just keep the spec as XML.

Wu: should the receiver reject the message if the wsa:Action value is incorrect?

<Bob> The [event source] is used as the target endpoint reference of the Subscribe message and is processed per WS-Addressing.

<Yves> dug; by "keep the spec as XML" you mean "easily transform the spec to infoset at publication time, and keep the master as XML" ? :)

Wu: add "REQUIRED" after "The"

<Bob> The REQUIRED [event source] is used as the target endpoint reference of the Subscribe message and is processed per WS-Addressing.

<Bob> The REQUIRED [event source] property is used as the target endpoint reference of the Subscribe message and is processed per WS-Addressing.

Agreed to replace the text:

/s:Envelope/s:Header/wsa:To The REQUIRED [event source] property provides the value of the WS-Addressing wsa:To element.

with

The REQUIRED [event source] property is used as the target endpoint reference of the Subscribe message and is processed per WS-Addressing.

No objection to replacement suggested by Bob

Gil: does the action property have type of wsa:action? Is there a type for an infoset property?

<gpilz> [action] : IRI (1..1)

<gpilz> [destination] : IRI (1..1)

<gpilz> [source endpoint] : endpoint reference (0..1)

Text under discussion: "[action]: wsa:[action]"

Bob: we need to review this for correct xml infoset syntax at some time.

<dug> Add this after the previous text we just agreed to: The REQUIRED WS-Eventing [action] property is mapped to the WS-Addressing [action] property.

<dug> hmm, or is the mapping the other way around

Gil: the action is of type "IRI" , however do we need to claim that wse action is always the same value as wsa:action property. Why do we need two properties? There is only one action header in the message.

<Bob> ask kat

wu: in the future wse action property value may not map directly to wsa action value

<dug> should it be [action]: http://.../Subscribe

<gpilz> [event source]: endpoint reference (1..1)

Katy: this should be type, not a value

<gpilz> [action]: IRI (1..1)

<dug> [action]: IRI

<dug> Identifies the semantics of this message - and MUST be http://.../Subscribe

Bob: question under discussion is what should be the proper syntax for the line "[action]: wsa:[action]"

Gil: an important question is whether wse should have its own action property, distinct from wsa:action property
... I do not believe wse needs its own action property

Li: I believe we should have wse action property, since its infoset needs to be complete on its own. If ws addressing is used, the wse action maps to the wsa action value. We are assigning a different contractual meaning to the two infoset properties.

Katy: The fact that we are using the infoset notation requires that we define an action value for eventing.

<DaveS> This should read [action]: IRI (1,1) which defines the type, and any thing about the value shoud go below

<Sreed> Test

<jeffm> yes, but i am muted

Wu: currently ws eventing is piggybacked on ws addressing. For completeness of modeling it is appropriate to have a property wse action

Dug: the reason we are using action is because we are using ws addressing. If addressing later adds a user ID propety would we need to add a new wse infoset property for this user ID property?
... was action is not really even necessary for wse
... eventing should define the minimum properties it needs

Wu: but it is in the current version of the spec, wse required the action value

Dug: yes addressing requires it, but why should the wse infoset require it?

Gil: I would take out wse:action as an infoset property, is is not an abstract property of ws eventing.

<DaveS> Delete [action] section from the red and grey.

<DaveS> In the white text below:

<DaveS> �� This property MUST have the value�http://schemas.xmlsoap.org/ws/2004/08/eventing/Subscribe

<dug> Gil - mex is now fixed (the ns/enum issue)

<gpilz> This element (a serialization of the WS-Addressing [action] property) MUST have the value "http://schemas.xmlsoap.org/ws/2004/08/eventing/Subscribe"

Li: expressed concerns about being tied too much to ws addressing. Having a separate property for wse is advantageous in my opinion.

Asir: I also prefer to just have the ws addressing property for action

Wu: I can accept the proposal from Dave S, to define use of wsa:action in the xml text itself, and remove the wse infoset property for action.

<Bob> This element (a serialization of the WS-Addressing [action] property) MUST have the value "http://schemas.xmlsoap.org/ws/2004/08/eventing/Subscribe"

above sentence replaces /s:Envelope/s:Header/wsa:Action This REQUIRED element provides the value of the [action] property. If a SOAP Action URI is used in the binding for SOAP, the value indicated herein MUST be used for that URI.

<Bob> in addition action would be removed from the red on grey text

delete wse:action as its own infoset property

<dug> http://www.w3.org/2002/ws/ra/edcopies/wsrt.html#put

replace

/s:Envelope/s:Header/wsa:Action This REQUIRED element provides the value of the [action] property. If a SOAP Action URI is used in the binding for SOAP, the value indicated herein MUST be used for that URI.

with

This element (a serialization of the WS-Addressing [action] property) MUST have the value "http://schemas.xmlsoap.org/ws/2004/08/eventing/Subscribe"

and remove action from wse infoset

<dug> s:Envelope/s:Header/wsa:Action

<dug> This required element MUST contain the value http://www.w3.org/2009/02/ws-tra/Get. If a SOAP Action URI is also present in the underlying transport, its value MUST convey the same value.

replacement text needs to include first line: /s:Envelope/s:Header/wsa:Action This element (a serialization of the WS-Addressing [action] property) MUST have the value "http://schemas.xmlsoap.org/ws/2004/08/eventing/Subscribe"

<dug> http://www.w3.org/2002/ws/ra/edcopies/wsrt.html#put

Replace: /s:Envelope/s:Header/wsa:Action This REQUIRED element provides the value of the [action] property. If a SOAP Action URI is used in the binding for SOAP, the value indicated herein MUST be used for that URI. With: /s:Envelope/s:Header/wsa:Action This element (a serialization of the WS-Addressing [action] property) MUST have the value "http://schemas.xmlsoap.org/ws/2004/08/eventing/Subscribe"

also delete the infoset parameter wse action

<jeffm> i'm just pleased as punch to approve

No objection to proposed change of deletion of infoset property wse action, and replacement of paragraph above

<jeffm> it's swell

Gil: this looks good for ws eventing, is this proposal just for ws eventiing? what about the other specs
... I am happy to apply this to ws eventing, I would like to see a similar set of markup text for the other specs as well.

Bob: the issue we are discussing is limited to the context of ws eventing.

<Geoff> +q

Bob: we can later open up new issues, one for each of the other specs, to do similar things

<dug> lunch! ;-)

Bob: We seem to have agreed to apply this the same way to all the specs, however we need to open specific issues for each of the other specs. The resolution of these new issues will require explicit text for approval by the WG.
... any general resolution would have to be followed by explicit text changes for each spec.

Geoff: is there a general agreement on this direction as a general resolution?

<jeffm> it is too hard to mute/unmute to say no objections

Discussion on whether we now have a fully enabling proposal to resolve Issue 6424.

<dug> Either way Wu will probably be doing the work ;-)

Bob: will anyone object to having the editors apply similar changes as a proposed resolution to the rest of the eventing spec sections, and also for all the other specs?
... will anyone object to having the editors apply similar changes as a proposed resolution to the rest of the eventing spec sections, and also for all the other specs?

<scribe> ACTION: [recorded in http://www.w3.org/2009/03/10-ws-ra-minutes.html#action01]

bob will create new issues to apply similar pattern to remainder of eventing spec and each of the other remaining specs.

<Bob> ACTION: bob will create new issues to apply similar pattern to remainder of eventing spec and each of the other remaining specs. [recorded in http://www.w3.org/2009/03/10-ws-ra-minutes.html#action02]

Bob: do we agree that the proposal (version 7) from Wu with the two text changes we approved above can resolve issue 6424?

No objection to resolve issue 6424.

<trackbot> Sorry, bad ACTION syntax

<trackbot> Created ACTION-33 - Will create new issues to apply similar pattern to remainder of eventing spec and each of the other remaining specs. [on Bob Natale - due 2009-03-17].

No objection to apply this pattern to the rest of the ws eventing and the other specs.

Break for lunch

<jeffm> okie, dokie - enjoy lunch

<li> drop off and see you at 1:00pm

<Bob> We are resuming

<Bob> scribe: David Snelling

<Bob> scribenick: DaveS

TAG Discussion

Ashok: The URI is the basis of the WWW. If the URI points to a Document and you do a Get, you get a document. If it point to a thing you get a "representation" of the thing, e.g. a picture of a house. The HTTP link-header form will contain links to metadata about the resource. This might be an approach we could take, e.g. point to the type of data we want about the resource.

<Bob> http://tools.ietf.org/html/draft-nottingham-http-link-header-03

Ashok: Should we consider using this strategy for getting access to metadata about a resource?

Bob: Other actives include SOAP over other protocols. This seems HTTP specific.

This is a generalization of Link_data to Http generally.

Bob: The "Team" comment with respect to transfer still stands as the supported TAG, e.g. why not just use URL's? and related issues.
... There are some processing implications: Caching of representations, proxies, etc. The TAG see these as advantages vs. what impact they have on our work.

Asir: Is this really important to TAG or should we just proceed?

Bob: The last time the WS-A group followed the public comment process.

Ashok: There was some concern that this working group might not start as a result of this issue. A lot of the problem centers on the EPR.

DaveS: This issue is very old, back to the initial WS-A discussions.

Dug: There isn't much we can do here. The cat is out of the bag sine EPRs.

Asir: Do we need to approach them before?

Bob: We should use this opertunity to plan.

Gil: Not all our specs actually require EPRs. E.g Subscription is all about SOAP.

<Ashok> Link Header draft: http://tools.ietf.org/html/draft-nottingham-http-link-header-03

<gpilz> to ammend the minutes: it is easier to defend the use of EPRs in some of our specs than others because some of them (e.g. WS-Eventing, WS-Enumeration) are more SOAP-oriented than others

Bob: First, the TAG talks about a lot of possible clients. We are much more SOAP only focused. These might XMLP related, rather than just http. We also use "posts" with is not so rest-ful.
... We could provide an "overlay". Define what would happen if a GET was passed to one of our "resources".

<Yves> SOAP 1.2 uses HTTP GET

<Yves> the state of implementation of this is... not widely deployed

Bob: This would give us the chance to preempt them or we could just wait. We should decide on this.

<Bob> cak dug

Dug: Transfer tries to walk a middle ground between http and SOAP. Options are abandon RPs or make a rest-ful equivalent. Similar problems with Mex. We should decide to prempt or not.

Bob: The TAGs concern is not a SOAP issue.

Asir: Tx is http over SOAP (over any soap binding).

<dug> no transfer is not http over soap - otherwise transfer is missing a ton of stuff

Asir: Tx is http over SOAP (over any soap binding)

Gil: Enum and Eventing are very focused specs. Only ever talked to by soap clients. people might want to do both with a Tx resource.
... We could describe a way to marshal RPs into ?-parms.

<asir> I think Gil is talking about how to map an EPR to an URI

Bob: we could do this as a WG note.

Yves: RPs are hard to do in ?-parms. There are also other parts of the message (context ext) that would need to be done. This is too much for this WG. We could define it for RP free EPRs.

<dug> +1 to Ashok - w/o a clear issue from someone/tag we're just guess at a solution to an unknown problem

Ashok: If no one wants to look at this, we should just wait.

Asir: The dual use use case is a good one with we might want to address.

Ashok: We can wait or be proactive.

Bob: Does anybody want to work on a proposal in advance of a comment from TAG?

<dug> run yves run

<jeffm> i do not believe in the pre-emptive doctrine

<asir> don't know proposal for what :-)

Asir: What about the on going discussin?

Ashok: There is no real outcome from this discussion.

<jeffm> i have another call to run - bob gets special exemption from attending since he is engaged in a far more important activity

<jeffm> i'll dial back in later if i can

<dug> Why didn't WSA have to answer the question of "what gets returned from a naked GET to an EPR?" ?

Asir: The WG will process any actual comments from TAG.

Bob: WS-A was never asked the question "what comes back" but a more abstract question was asked answered - accordingly.

Resolution: No one is interested at this time in preparing a premptive proposal.

<dug> 6400 - proposal: http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Mar/0051.html

Issue 6400 - Eventing-SubscriptionEnd violates WS-I BP

Discussion and clarification.

Wu: Do we put this new PortType into the spec? How does it change the spec.

Dug: Simply remove some an add a new porttype.

resolved: Accepted.

<Bob> acl li

Li: Does this imply push only semantics?

Gil: It seems ok.

Bob: Postone overnight for thinking.
... updated bugzilla.

Issue 6425 - Eventing-Clarify How to Address Event Source

<Bob> Proposal at http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Feb/att-0112/00-part

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

Li: Closely related to the discussion this morning about [event source].

Gil: There seems to be a lot of implicit (indirect) knowledge needed to understand this.

Dug: Is this really about all entities, or just event source, e.g. EndTo, etc.

<Geoff> +q

Gil: They are all EPRs.

<gpilz> wse:NotifyTo, wse:SubscriptionManager, wse:EndTo

Li: We could make it a blanket statement.

Dug: We should do this in all specs. Or borrow text from one of the other specs.

<asir> Transfer Web Service Resource: A resource is a Web service that is addressable by an endpoint reference [WS-Addressing 1.0 Core] and can be represented by an XML Infoset. The resource's representation can be retrieved using the Get operation defined in [WS-Transfer].

Geoff: Doesn't the infoset work cover this?

Wu: Maybe, but would prefer to see it stated explicitly.

<asir> And a metadata resource is defined as ...

<asir> When the representation of a resource is mex:Metadata, as defined in Section 4, or any other document format (e.g. [XML Schema: Structures],[XML Schema: Datatypes], [WSDL 1.1], [WS-Policy]) for which a mex:MetadataSection/@Dialect has been defined, then the resource is referred as 'metadata resource'. The representation of a metadata resource MAY be retrieved and/or updated as any other [WS-Transfer] resource. Specifically, the representation of a metadata resource M

<dug> All messages defined by this specification are sent to a Web service that is addressable by an endpoint reference [WS-Addressing 1.0 Core] and can be represented by an XML Infoset.

<dug> All messages defined by this specification are sent to a Web service that is addressable by an endpoint reference [WS-Addressing 1.0 Core].

<dug> All messages defined by this specification are sent to a Web service that is addressable by an EPR [WS-Addressing 1.0 Core]

Resoltion: Agreed to the above text.

<asir> where would you put it?

Bob: This resolves 6425, but there is general agreement that this approach should be used in all the specs.

DaveS: Put thsi text in where the first refference to a rsource is described.

Issue 6428 - Eventing: Separate Event Delivery Mode and Format

<dug> Wu -don't you have a newer proposal?

<Bob> http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Feb/0020.html

<Geoff> we would prefer attributes

Dug: The element approach is better for extensibility.

Geoff: This seems overly complicated. We would prefer simple solutions.
... What about policy?

Ashok: Policy should be easier with element approach.
... Extension is about what we don't know now. So the most open approach is best.

Resolution: Li to do an element oriented proposal, e.g format as an element.

6429 - Eventing: Standardize Wrapped Event Sink

Li: Basically add action URI to notify element.

<Bob> ACTION: Li to prepare an element based proposal for issue 6428 [recorded in http://www.w3.org/2009/03/10-ws-ra-minutes.html#action03]

<trackbot> Created ACTION-34 - Prepare an element based proposal for issue 6428 [on Li Li - due 2009-03-17].

Gil: Should the action be a header rather than an attribute in the body?

Dug: 1) Use a single service for all wrapped messages. Then the application needs this information and the app has the body.

2) Defining new formats needs includes other information that might be needed for one service to deal with multiple styles.

<Bob> ?

Katy: Is there a way a bad action URI could cause a fault?

Ashok: Only if the service didn't recognize the action.

Dug: Note that to unwrap a wrapped message, use the actionURI as the was:action in an unwrapped message.

Gil: I would like to do a counter proposal.

<scribe> ACTION: Gill to write a counter proposal to 6429. [recorded in http://www.w3.org/2009/03/10-ws-ra-minutes.html#action04]

<trackbot> Sorry, couldn't find user - Gilbert

<Bob> ACTION: Gilbert to write a counter proposal to 6429. [recorded in http://www.w3.org/2009/03/10-ws-ra-minutes.html#action05]

<trackbot> Created ACTION-35 - Write a counter proposal to 6429. [on Gilbert Pilz - due 2009-03-17].

Break.

Discussion of what next.

Issue 6404 - MEX- define the MEX dialect

<Bob> proposal at http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Feb/0061.html

Li: Clarify that Gil will develop a counter proposal only to the action URI part of the proposal, not the rest.

Gil: Agreed.

Geoff: Issues specific to Policy , Policy Attachment, and Schema. Do these make sense?

Gil: It is unclear what policy attachement means. WSDL and Schema are clear. and polocy is not so bad.

Dug: Grouping is arbitrary. Everything returned is service specific. The proposed definition meats the intent of the spec.

Ashok: If a dialect is not specified, can you return just anything? Im therefore uncomfortable.

Geoff: This is the "Whatever" issue.

<dug> s/Whatever/Whateva/ :-)

Geoff: The MEX group is what the default would be. But also other stuff could also be sent.

Dug: This is what I proposed.

Geoff: No dialect = everything, MEX = those specified in the MEX specification.

<dug> Dug proposal: no dialect = mex, mex = everything client can see

Gil: No dialect = everything leaves open doors to other formats.
... why woould I ask for stuff I didn't understand?

Geoff: I know what I expect from some other context.

Ashok: Counter proposal - MEX = policy, schems, WSDL, ALL = everything you know. Prohibit nothiing.

geoff: Would like a default.

Dug: First resolve what the dialects mean.

<asir> Thanks Dug

Discussion about postponing this discussion pending other issues. All agreed.

Issue 6639 - MEX: make actionURIs consistent

Dug: Make it like the other 5 specs.

resolution: Agreed to 6639 as proposed by Dug.

Issue 6604 - MEX: Define a way to ask for more than one MEX dialect

Dug: Three choice, one dialiect, no dialect, MEX dialect, but no way to say what the client wants.

katy: What if the client can't return everything requested.

Dug: This is covered in the spec - empty section

Gil: What about duplicates?

Dug: Up to the service.

Asir: This is an optimization of multiple requests.

Geoff: If this enough, or do we provide a complete dialect selection language?

Asir: What about the migration path?

Ashok: There will be other changes. I don't believe this is required by the charter.

<gpilz> The Web Services Resource Access Working Group will take as its starting point the Member Submission versions of WS-Transfer, WS-ResourceTransfer, WS-Enumeration, WS-Eventing and WS-MetadataExchange. In order to avoid disrupting the interoperability of existing implementations, WS-MetadataExchange, WS-Transfer, WS-Eventing and WS-Enumeration should remain compatible with protocols and formats that depend on them, and offer a smooth migration path from the submis

<gpilz> "offer a smooth migration path"

<Yves> smoothness is in the eye of the beholder

Resolution: Agreed to the proposal to 6604 as in comment #1

There was some general discussion around how we address our charter requirement to "offer a smooth migration path". This is a separable issue, but Bob plans to track which issues may need migration actions later.

Bob: Will someone write a proposal.

<scribe> ACTION: Geoff to write a draft proposal for management of migration notes. [recorded in http://www.w3.org/2009/03/10-ws-ra-minutes.html#action06]

<trackbot> Created ACTION-36 - Write a draft proposal for management of migration notes. [on Geoff Bullen - due 2009-03-17].

Issue 6500 - MEX: Wrappers around GetMetadata

Geoff: For consistencey with the resolution 6398.

<dug> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6500

Katy: Proposed just renaming the Metadata element and moving the any.

<dug> <mex:MetadataSection...> ... </mex:MetadataSection> *

<dug> xs:any *

<dug> <mex:MetadataSection...> ... </mex:MetadataSection> *

<dug> xs:any *

Asir: Is there really any change needed.

Gil: But what about xs:any.

<scribe> Postponed to tomorrow.

Issue 6676 - WS-MEX 'pollicy attachment' dialect is underspecified

Ashok: Policy covers the whole space any way.

Asir: The dialect define the type of the returned element. In policy attachment case, it says it is here.

Ashok: The spec says policy can be attached to various places.
... We need an example.

Asir: It returns a policy attachement association to external policy.

Postpone while people talk to home.

Topic 6675 - WS-MEX 'pollicy' dialect is underspecified

6675 - WS-MEX 'pollicy' dialect is underspecified

Gil: There are many policy types and where they can be attached, it need to be clearer what is meant by the dialect.

<dug> so, in irc I have two tabs - a #ws-ra one and one for irc.w3.org:6665 - how does irc decide which msgs go to which tab? some appear to go to both.

Asir: All the dialect says in the format of the message, not about what it means.
... The semantics is included in the metedata elements returned.

Dug: Clarification: they may only mean something if they are understood including relationships.

Asir: yes.

Gil: Whay just ask for policy?

Dug: Look for updates.

Gil: Maybe we just need to spell out just how little information is implied by MEX. e.g. just format and version.

Dave: If we just specific type etc, why are any of these included in MEX.

Dug: Either we include each URI and define them or do nothing.

Asir: The list is extensible.

Dug: What is in a WSDL respons only the binding is included?

Dave: Could we just describe a namespace URI?

Gil: It should really point to a schema element.

Complicated multi part example discussed.

Bob: This is probably not the right issue for this discussion.
... Propose close without action 6675.

<scribe> ACTION: Gil to raise issue for explanatory text wrt 6675. [recorded in http://www.w3.org/2009/03/10-ws-ra-minutes.html#action07]

<trackbot> Sorry, couldn't find user - Gil

Bob: Propose to close 6676 with no action.

resolution: close 6676 and 6675 with no action

<Bob> ACTION: Gilbert to raise issue for explanatory text wrt 6675. [recorded in http://www.w3.org/2009/03/10-ws-ra-minutes.html#action08]

<trackbot> Created ACTION-37 - Raise issue for explanatory text wrt 6675. [on Gilbert Pilz - due 2009-03-17].

Bob: Near closing, so lets discuss schedule for tomorrow.

All: agreed.

<li> bob, we'd like to postpone 6430

Bob: Please would all group members please look over the IRC chat now and raise issues now.

Li: Postone 6430 until after 6401 and some others relates.

<jeffm> bye

Resessed in 9:00 March 11.

<li> bye

<Yves> bye

- DRAFT -

Web Services Resource Access Working Group Teleconference

10 Mar 2009

Attendees

Contents

IRC admin

timing of issue discussions

Minutes of prior meetings

Revised agenda

WG Administrivia

New Issues

Issues with proposals

TAG Discussion

Issue 6400 - Eventing-SubscriptionEnd violates WS-I BP

Issue 6425 - Eventing-Clarify How to Address Event Source

Issue 6428 - Eventing: Separate Event Delivery Mode and Format

6429 - Eventing: Standardize Wrapped Event Sink

Issue 6404 - MEX- define the MEX dialect

Issue 6639 - MEX: make actionURIs consistent

Issue 6604 - MEX: Define a way to ask for more than one MEX dialect

Issue 6500 - MEX: Wrappers around GetMetadata

Issue 6676 - WS-MEX 'pollicy attachment' dialect is underspecified

6675 - WS-MEX 'pollicy' dialect is underspecified

Summary of Action Items

Scribe.perl diagnostic output