See also: IRC log
<trackbot> Date: 06 November 2009
<Bob> scribe: Wu
bob: email sent to mailing list to update the issues
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
asir: we need more time
... to settle use cases with my team
http://www.w3.org/Bugs/Public/show_bug.cgi?id=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
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
<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.
http://www.w3.org/Bugs/Public/show_bug.cgi?id=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/
http://www.w3.org/Bugs/Public/show_bug.cgi?id=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
<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/
we expect a new version of the state table to appear at a future meeting.
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
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.
@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
Put(Frag).
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.
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
attributes)
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
<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.
<Bob> http://www.w3.org/Bugs/Public/show_bug.cgi?id=8157
Define an EmptyFilter fault like we did for eventing
per
http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Mar/att-0077/00-part
Gil: it seems like a good idea to me
Ram: I would like to defer resolution until later.
http://www.w3.org/Bugs/Public/show_bug.cgi?id=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.
http://www.w3.org/Bugs/Public/show_bug.cgi?id=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.
http://www.w3.org/Bugs/Public/show_bug.cgi?id=8163
RESOLUTION: No objection to resolve issue 8163 as proposed.
http://www.w3.org/Bugs/Public/show_bug.cgi?id=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".
http://www.w3.org/Bugs/Public/show_bug.cgi?id=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.
http://www.w3.org/Bugs/Public/show_bug.cgi?id=8168
RESOLUTION: No objection to resolve issue 8168 as proposed.
http://www.w3.org/Bugs/Public/show_bug.cgi?id=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.
http://www.w3.org/Bugs/Public/show_bug.cgi?id=8170
Martin: change "demarshalling" to "unmarshalling"
RESOLUTION: No objection to resolve issue 8170 with proposed change in comment #2 from bugzilla
http://www.w3.org/Bugs/Public/show_bug.cgi?id=8172
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
http://www.w3.org/Bugs/Public/show_bug.cgi?id=8177
RESOLUTION: No objection to resolve Issue 8177 as proposed.
http://www.w3.org/Bugs/Public/show_bug.cgi?id=8179
RESOLUTION: No objection to resolve Issue 8179 as proposed.
http://www.w3.org/Bugs/Public/show_bug.cgi?id=8184
RESOLUTION: No objection to resolve Issue 8184 as proposed.
<Bob> Issue 8186
<Bob> RESOLUTION: 8186 resolved as proposed
http://www.w3.org/Bugs/Public/show_bug.cgi?id=8162
RESOLUTION: No objection to resolve issue 8162 as proposed
http://www.w3.org/Bugs/Public/show_bug.cgi?id=8199
RESOLUTION: No objection to resolve issue 8199 as proposed.
http://www.w3.org/Bugs/Public/show_bug.cgi?id=8213
RESOLUTION: No objection to resolve Issue 8213 as proposed
http://www.w3.org/Bugs/Public/show_bug.cgi?id=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
http://www.w3.org/Bugs/Public/show_bug.cgi?id=8204
RESOLUTION: No objection to resolve Issue 8204 as proposed.
http://www.w3.org/Bugs/Public/show_bug.cgi?id=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.
http://www.w3.org/Bugs/Public/show_bug.cgi?id=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
s/7555/7554/
http://www.w3.org/Bugs/Public/show_bug.cgi?id=8181
agreed to defer discussion since it is not editorial.
http://www.w3.org/Bugs/Public/show_bug.cgi?id=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