Web Services Resource Access Working Group Teleconference

06 Nov 2009

See also: IRC log


Alessio Soldano, Red Hat
Ashok Malhotra, Oracle Corp.
Asir Vedamuthu, Microsoft Corp.
Bob Freund, Hitachi, Ltd.
Doug Davis, IBM
Fred Maciel, Hitachi, Ltd.
Gilbert Pilz, Oracle Corp.
Jeff Mischkinsky, Oracle Corp.
Katy Warr, IBM
Li Li, Avaya Communications
Martin Chapman, Oracle Corp.
Ram Jeyaraman, Microsoft Corp.
Sreedhara Narayanaswamy, CA
Tom Rutt, Fujitsu, Ltd.
Vikas Varma, Software AG
Wu Chou, Avaya Communications
Yves Lafon, W3C/ERCIM
Bob Natale, MITRE Corp.
David Snelling, Fujitsu, Ltd.
Mark Little, Red Hat
Orit Levin, Microsoft Corp.
Paul Fremantle, WSO2
Paul Nolan, IBM
Prasad Yendluri, Software AG
Bob Freund, Hitachi, Ltd.
Wu Chou, Tom Rutt


<trackbot> Date: 06 November 2009

<Bob> scribe: Wu

bob: email sent to mailing list to update the issues

New Issue Moriatorium

gil: we ask time to Friday next week to finish the review

bob: any objection to extend the deadline to close on 11/13/09?

RESOLUTION: no objection. New Issue Moratorium will begin at COB on 2009-11-13

issue 8031

asir: we need more time
... to settle use cases with my team

issue 7728


gil: point 2 of 7728 is already addressed.
... point 1 of issue 7728 is the one to address

<gpilz> http://www.w3.org/Bugs/Public/attachment.cgi?id=775

gil: this is the attachment for point 1 of issue 7728

tom: likes it.

asir: we had some discussion on this issue over mailing list.

<asir> Here it is http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Nov/0048.html

asir: there are two assumptions. First assumption - policy at EPR applies to all
... second - consumer knows almost everything
... thinking points: who defines it, what is the relation between policy sitting in EPR and out-of-band agreement,
... what is the policy subject

gil: i think may not need to address since it is quite common.

regarding your point A. point B needs to explore.

gil: we need to more clear for point C.

asir: regarding point A, it may not be common for other people.

<trutt> The ability to attach a policy expression pertaining to the endpoint as a whole to an epr, would be used in cases where there are not concerns about policy conflicts at a more granular level.

<Zakim> asir, you wanted to ask a question

asir: this proposal is out for long time, anyone has implemented it?
... it has been there for 2 1/2 years.

<gpilz> The policies attached to an EPR in this matter apply to all bindings, portTypes, operations, and messages associated with the endpoint referenced by the EPR.

bob: the WG has its own charter. We should be regard of our own charter/interest.
... there seems point C can be crisper.

<gpilz> The policies attached to an EPR in this manner apply to all bindings, portTypes, operations, and messages associated with the endpoint referenced by the EPR.

gil: the posted text is trying to address point C

asir: it is o.k. to say these assumptions are made.
... for example in section 8 of MEX that assuptions are positively documented.

bob: AI on Gil/Asir to work on a refresh version of proposal for issue 7728

issue 8124

dug: http://www.w3.org/Bugs/Public/show_bug.cgi?id=8124
... I don't see to split the namespace for policy
... I don't see real benefit of it.

ram: is there a value to change value in policy space which is isolated?

dug: it might cause more confusion.

gil: the chance to change policy only peice is small.

bob: it seems a coin flap choice in this case.
... we have examples that go both ways.
... the proposal is to consolidate the namespace.

asir: what is the harm of having two separate docs?

dug: cann't see real benefit.

asir: separate data and meta data is one benefit.

jeff: physically separation does not mean much.

dug: it is easy to read.

bob: any objection to proposal?

RESOLUTION: no objection. issue 8124 is resolved with single namespace proposal

issue 7911

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

Yves: my point to put a warning in the text, that people should be aware the possible descripency with some warning text.

<gpilz> {some combo of specs} allows receivers to dispatch on either the [Action] property or the QName of the [Body] child. Implementations that authorize requests based on the requested operation are advised to ensure that the property values used for such authorization decisions are consistent with the property values that are used for dispatching.

gil: adding the above sentence in security section should do the trick.

ram: why just limit to two options, there may be other ways.
... If there are multiple ways, the first sentence can be dropped.

Yves: first sentence is to describe the issue and non-binding

asir: confused from a different view about the proposal

bob: any text change proposal?

asir: needs to think about it.

bob: any objection to resolve this issue as Gil's text?

asir: needs more time.

bob: Gil puts this proposal into bug proposal and discuss in future meeting

<dug> Event Source : A Web service that accepts requests to create subscriptions for the subscriber to receive certain type of notifications.

<dug> http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Nov/0022.html

<asir> Asir mentioned that MSFT needed more time to work on 7911 because we have so many WS-RA work items scheduled for the next WG meeting


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

bob: please post the consolidated proposal of issue 7970

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

ram: why sending notifications is not mentioned in event source
... if we may add event source may send notifications

dug: proposal to move "notifications may be sent by any ..." to the definition of event source

bob: remove term "notification"

dug: i am o.k. but it should be raised as a separate issue.

<dug> (if there's any push-back)

bob: propose to remove "one-way" in notification to "a" message.

gil: "one-way" in the definition of notification is not clear.

bob: any objection to accept comment #8 as resolving issue 7970?

RESOLUTION: no objection. Issue 7970 is resolved with the latest comment in the bugzilla.

issue 7986


gil: what happens if a subscriber request to event source, and the policy in that Notify EPR does not match the policy this proposal advertising?
... we might need adding a new fault for this.

dug: that is fine

asir: if there is descripency, it is caused by the provider, right?

<asir> Our comments are here http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Nov/0012.html

gil: this is not my concern. what happens policy in subscribe does not match the policy being published by provider.

asir: when you get back notification wsdl, it may be able to stay alone and maynot.
... we would like to have a method to get all meta data, not just wsdl.

dug: if you want to get missing meta information, why just ask for it specifically.

gil: ask schema should get all schemas the endpoint knows about.

asir: this is point, why we need to add new dialect if this is the case.

dug: if metadata is optional, implies imcomplete metadata (e.g. has policy but not wsdl)

can happen. Do we need to solve the problem to get policy where is no wsdl?

dug: asking notification policy is something of interest and special.

<jeffm> +q

gil: all metadata are optional. There is a use case that event notification type does not have wsdl.

dug: it might solve this issue by putting this policy in endpoint.
... it applies to event sink endpoint.

jeffm: optional is not helpful.

asir: there are two kinds of metadata: service metadata and notification metadata. If they separate, the problem might be solved.

<jeffm> what i said was that repeating the "its optional mantra" is not helpful,because we are writing a MetaDATA spec which says what to do and how to specify the metadata when it is there

dug: why we just create a new dialect "notification policy"?
... if using separate dialect, it will separate different cases.

asir: you are heading to the design pattern using dialect to do division.

gil: in mex, two class uris can use, e.g. generic (all), and specific (schema).

bob: two choices i.e. notification wsdl is wsdl or not.

dug: similar problem as discussed yesterday, implicit wsdl or real application wsdl. we need a flag to tell.

bob: one alternative to call these dialects collection uri

dug: it means using a list of qualifiers

bob: you can have three categories dilects, collection identifiers, and qualifiers.

AI: Asir/Doug come back with new solution proposal.

<dug> Gil too

<asir> s/"Asir/Doug"/Asir, Doug and Gil/

issue 8198


ram: i would be fine to be the owner of this issue.
... the problem is: people wants to link wsdl at the design time, and if there is a mechnism on it.

dug: may just pass the meta data document, one with notification wsdl and one with event notification. would that work?
... i am poking what solution will solve this problem.

gil: mex meta data document contains both. The linkage is they are in the same meta data document.

asir: the mex you can infer is "collection". Any inference to be drawn is out of band.

<Bob> recessed until 13:00 pacific

<Bob> scribenick: trutt

issue 8068

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

<gpilz> +1

Dug: some people would like to see the Event Description section (A.1) pulled out into a separate document/spec.

Ram: what would be title of he new little spec?

Dug: we have to decide on that

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

Dug: there would be a reference from ws-eventing to this "little" spec

Asir: what is the use case. Are there other specs which want to use it?

Martin: SCA eventing might want to use it

<asir> Here is a sentence that won't make sense in a separate doc

<asir> The /soap:Envelope/soap:Body/wse:Notify element has a single child element

RESOLUTION: No objection to a directional resolution to have editors to proceed with pulling out the Event Description (A.1/A.1.1) as a separate small specification

<gpilz> http://www.w3.org/2002/ws/ra/

Issue 6435

we expect a new version of the state table to appear at a future meeting.

Issue 7791

Consistent Policy applied to a set of resources http://www.w3.org/Bugs/Public/show_bug.cgi?id=7791

Dug: I would prefer to give Paul an email explaining that if he does not provide a proposal, the issue would close with no action

Ownership assigned to Asir

Asir to urge Paul to provide a proposal for resolution

Gil: this seems to want to introduce yet another scope selector (or axis) on the resource metadata to be returned.
... any proposal needs to take into consideration the other proposals regarding meta data scope, like app vs implicit wsdl, notification vs regular wsdl, etc.

Asir: so Paul needs to motivate the need, and relate to the other issues on metadata scope which we are working on.

<asir> and provide a concrete proposal

Issue 8201

Clarify required and optional operations http://www.w3.org/Bugs/Public/show_bug.cgi?id=8201

Ram: I suggest that all WG members look at my characterizations of the optionality of each operation, and comment on them so we can come to resolution.

Dug: I have a concern about why getStatus should not just be required.

Ram: if there is a general requirement for this feature, we can make it mandatory. I want to ensure there is a valid use case for requiring get status operation always.

<Bob> scribenick: trutt

Wu: I am happy with the general idea, but we need to agree on the actual set of mandatory operations.

Dug: ws frag does not need to say anything about get or put, because they are inherited from ws transfer.

<Bob> scribenick: trutt

Bob: what should we do about get status? Should it be required?

Wu: I need time to check on the need for get status before I decide

<scribe> ACTION: Ram to produce a concrete proposal based on his email. [recorded in http://www.w3.org/2009/11/06-ws-ra-minutes.html#action01]

<trackbot> Created ACTION-119 - Produce a concrete proposal based on his email. [on Ram Jeyaraman - due 2009-11-13].

s/proposal based on/proposal for operations being required/optional, based on/

Dug: I suggest Ram pick a spec, and do an exemplar of how to specify the optionality. Perhaps eventing would be best to do it.

Issue 7774

@mode in ws-frag is harmful http://www.w3.org/Bugs/Public/show_bug.cgi?id=7774

Yves: Get rid of '@mode' and use Create(Frag) Delete(Frag), like it's done for


Yves: could Dug explain the reason for this @mode

Gil: ws frag is extending ws-transfer. verbs in ws-t have a context. a ws-t put is on resource as a whole. The insert is creating a new bit of fragment, however from view of ws-t it is acting on the resource as whole. It is changing the resource even though it is removing a piece of the resource.

Yves: what is fragment identifying. Is the verb on the whole resource of just the fragment.

Dug: with put you may delete a bit, but it is still an instruction to update the resource. that is why put is the best verb rather than a delete.
... the dialogue URI could be used to accomplish your patch example.
... I would like to think more about whether we could get rid of remove mode and instead use an empty value with a put.
... may need to distinguish missing value and empty value

Defer resolution until after further email discussions.

Issue 7969

Fragment: clarify behavior of optional xml http://www.w3.org/Bugs/Public/show_bug.cgi?id=7969

Dug: Add the following sentence to the end of the paragraph referenced above:

When @Mode is 'Insert' or 'Replace', any optional values (element or


within this subset that are not specified in the wsf:Value element will be set

to a resource-specific default value.

RESOLUTION: No objection to resolve issue 7969 with proposal in issue

issue 8191

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

serialization of fragment Put input is underspecified http://www.w3.org/Bugs/Public/show_bug.cgi?id=8191

<gpilz> http://www.w3.org/2002/ws/ra/edcopies/wsfrag.html#XPathL1

Gil: In the descriptions of the "XPath Level 1" and "XPath 1.0" expression

languages, WS-Fragment describes some important serialization rules for text and attribute nodes, however it does not say if or how such rules should be applied to /wst:Put/wsf:Fragment/wsf:Value's.

Gil: does the spec require to wrap text values for an attribute as in a get, or can the value be used on its own.

Dug: If there are more than one value returned, the wrapper may not be needed. Xpath level 1 does not return more than one value, so the wrapping might not be needed.
... You might not need it for a put if there is no need to send more than one value on the request. I see no need for such a separator on the input side of a put.

<gpilz> <wsf:Value>1</wsf:Value> or <wsf:Value><wsf:TextNode>1</wsf:TextNode></wsf:Value> ??

Gil: if I am trying to replace a text node with ws-frag put, do I use the first form or the second form in the example above. The spec needs to be clear on this.
... how to serialize attribute node and text node values on the ws-frag put.

<asir> Gil wants clarity nothing is broken tho

Dug: we need to go off and think about this. I expect you do not need it on the input of the put operation.

Gil: If I use the response from a get operation to later use in a subsequent put, it might be beneficial to not require a change in the way the value is wrapped.

Dug: I do not see a need to put a sequence of values.

Bob: a streaming processor can deliver a text node as a sequence of text rather than as a whole.

Asir: Xquery serialization deals with this already. We should look at that.

<asir> here it is http://www.w3.org/TR/2007/REC-xslt-xquery-serialization-20070123/

Agreed to leave this issue open to further investigation and discussion.

issue 8157

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

Define an EmptyFilter fault like we did for eventing



Gil: it seems like a good idea to me

Ram: I would like to defer resolution until later.

Issue 8158


In example 3.1 proposal:

change (20) to be:

(20) <wsen:Expires min="PT10M"> PT10M </wsen:Expires>

RESOLUTION: No objection to resolve 8158 with proposal.

Issue 8160


check to see if all "required" uses are meant to be RFC2119 uses

Asir: it is not a global change of "required" to "REQUIRED". eg accountabiliy in security section should not be a keyword.

Dug: this applies to enumeration as well.

Agreed to defer resolution until all the uses of the word "required" are examined individually.

Agreed to change "needed" to "used" in the two exceptions that are listed in the issue proposal.

Issue 8163


RESOLUTION: No objection to resolve issue 8163 as proposed.

Issue 8166


RESOLUTION: No objection to resolve Issue 8166 with change from: "The term "subscription manager" in this specification refers to" to "The term "subscription manager" is used in this specification to refer to".

Issue 8167


Asir: reconsider, since we have to edit the paragraph to remove rfc 1119 terminology.

Agreed editor to remove rfc 2119 keywords from the paragraph cited in the bug.

RESOLUTION: No objection to resolve 8167 with amended proposal to remove rfc 2119 keywords from paragraph.

Issue 8168


RESOLUTION: No objection to resolve issue 8168 as proposed.

Issue 8169


<gpilz> However, if a subscriber wishes to have notifications annotated with unique SOAP header blocks then it MAY include reference parameters within the wse:NotifyTo element. These reference parameters will be processed as specified by WS-Addressing 1.0 - SOAP Binding.

RESOLUTION: No objection to resolve issue 8169 with proposed change in comment #1 from bugzilla.



Martin: change "demarshalling" to "unmarshalling"

RESOLUTION: No objection to resolve issue 8170 with proposed change in comment #2 from bugzilla



Tom: change "and MUST" to "which MUST" in the proposal

RESOLUTION: No objection to resolve issue 8172 with proposed change in comment #1 from bugzilla

Issue 8177


RESOLUTION: No objection to resolve Issue 8177 as proposed.

Issue 8179


RESOLUTION: No objection to resolve Issue 8179 as proposed.

Issue 8184


RESOLUTION: No objection to resolve Issue 8184 as proposed.

<Bob> Issue 8186

<Bob> RESOLUTION: 8186 resolved as proposed

Issue 8162


RESOLUTION: No objection to resolve issue 8162 as proposed

Issue 8199


RESOLUTION: No objection to resolve issue 8199 as proposed.

Issue 8213


RESOLUTION: No objection to resolve Issue 8213 as proposed

Issue 8214


Dug: Katy meant for them to be siblings.
... I say make the text agree with the schema.

RESOLUTION: No objection to resolve Issue 8214 as proposed

Issue 8204


RESOLUTION: No objection to resolve Issue 8204 as proposed.

Issue 8178


Dug: this is superceded by Issue 8201.

RESOLUTION: No objection to close as supercedec by Issue 8201

Bob: It is time to get another snapshot. Can the changes get into the editor's drafts before the snapshot.

Yves: monday morning would be a good time for the snapshot.

Dug: I can do it by Monday morning EST.

Bob: Dug should tell Yves when he has incorporated the changes.

Issue 8176


Asir: I recall that this is reconsidering an issue from Hursley that we resolved.

Agreed to leave open to allow investigation of Hursley discussion


Issue 8181


agreed to defer discussion since it is not editorial.

Issue 8200


Dug: mex-all IRI can never appear in a metadata section. So the table is misleading.

Asir: I need more time to invistigate why it was put in originally.

Dug: I think it was just a copy from the request table.

Agreed to keep issue open for more time

Summary of Action Items

[NEW] ACTION: Ram to produce a concrete proposal based on his email. [recorded in http://www.w3.org/2009/11/06-ws-ra-minutes.html#action01]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.135 (CVS log)
$Date: 2009/11/19 16:32:43 $