See also: IRC log
<trackbot> Date: 02 October 2009
<Bob> scribe: Ram Jeyaraman
<Ram> scribe ram
<Bob> scribenick: Ram
<Bob> proposed xsd/wsdl at http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Oct/0010.html
RESOLUTION: XSD/WSDL from Doug looks good. No objections to publishing WS-Fragment as a FPWD.
Doug: The text in 7.2 is the old
text; says you can advertise the policy.
... In the new text, I changed policy to metadata.
... This is an initial pass at what we discussed day before.
Asir: Two comments.
... These two paragraphs there are a continuation of the para under 7.2. When a dialect URI is defined we need to provide an identifier. Not defining is fine but we need to call it out.
Doug: There were some reading flow
issues; so i did it this way.
... I am fine with rearranging it if it improves the flow.
Asir: There is one semantic change relating to the identifier; identifier is not defined.
No objections so far on the suggested change.
Jeff: why does this proposal still talk about XML SOAP URI?
Doug: We don't have a standard version for it.
Bob: The WSDL dialect is defined in the MEX specification.
Jeff: Should the dialect URI use a WS-RA namespace?
Bob: You should consider filing an issue.
Jeff: When are the operations exposed.
Asir: When the applications want to expose them.
<Bob> from comment #2 of Issue-6694 (directional decision during the August F2F)
<Bob> RESOLUTION: (directional) everything is implicitly defined with WS-Policy
<Bob> assertions, optionality of operations to be indicated by assertions or some
<Bob> other appropriate WS-Policy mechanism. In addition the wsdl will be in the
Katy: If a decision had been previously made not to put explicitly in the WSDL, the quoted resolution does not contradict it.
Wu: My understanding is that by using the policy assertion the endpoint is declaring implicit support for all the operations.
<gpilz> s/indicate that a certain security algorithm is needed to use the WS-Transfer operations./indicate that a specific security mechanism is used to protect the WS-Transfer operations for this endpoint./
Asir: Two a concrete change. Change 'while' to a 'when';
Gil: Should there be a statement that operations cannot explicitly appear when the policy assertion is used?
Asir: This is in the first paragraph of section 7.
Wu: I want to see a clear declartion that I support WS-Transfer operations.
Bob agrees with Asir's comment.
Wu does not agree with Gil's point.
Bob: We have already agreed that if the policy assertion is present, then all operations are implicitly supported.
Wu: The policy assertion section covers many things beyond just the implicit behavior.
<Yves> implicit declaration doesn't forbid explicit and more tuned declaration
<Yves> implicit means "it's not defined, resort to using this"
Katy: The text already covers all the
possible options. Transfer is implicitly defined, explicitly
supported, not suported.
... Not supported implies Not a Transfer resource.
... It strikes me that there has been a clear decision about not openly supporting explict option.
Bob: The specification does not
require use of policy or WSDL.
... Although we have said that policy is not the exclusive way, but if policy is used, that implicitly defines the operations.
... True or not?
Martin: It is ambiguous whether it is implicit or explicit.
Bob: The meaning of the existence of the policy indicates Transfer is supported. Implicitly or explicitly supported is undefined.
<Wu> There should be a specific policy assertion to indicate that the operations are implicitly supported.
Bob: Do we agree that when the policy assertion is present, the operations are implicitly defined?
Doug: Whether policy is used or not has no bearing on whether it is implicit or explicit.
Bob: If the policy assertion exist, what does it mean?
Doug: All it means is, service is advertising support for transfer. Meaning, transfer operations are supported.
Asir: The policy assertion indicates
you are supporting the required operations and with the policy
params it supports the optional operations.
... When an endpoint supports policy, and Transfer, and uses policy assertion, it is indicative of the operations being supported implicitly.
Bob: We don't want to revisit earlier agreements. The resolution to 6694 indicates that when policy assertion is engaged implicit support of operations is expressed.
Gil is describing an use case.
Gil is defining an application WSDL that contains the Transfer operations. The policy appears in the WSDL as well.
Asir: It is redundant.
Gil: Is it illegal?
Doug: The policy assertion is indepent of implicitly.
Bob: We discussed that we had
previously discussed that what is infrastructure for one person is
infrastructure for another person.
... The resolution text for 6694 stands.
Katy: This was a mechanism for operations that do not explicitly appear in the WSDL.
Dave: The red text in the proposal is capturing the cases that are not covered by the resolution to 6694.
Martin: If you have a policy and dialect explicitly defined, there is no clarity.
Bob: That is a separate
... Does the proposed modification sufficiently addressed 6721?
<paul> I took myself off the queue. I personally don't agree that WSTransfer is purely 100% infrastructure, but that is a side issue
Asir: Let us remove the phrase "While the WS-Transfer operations are not exposed in an endpoint's WSDL" from the red text in the proposal.
<asir> Paul - I don't agree that Transfer is just infrastructure. Bob said it well ... one man's infrastructureis another man's app
<paul> i thought we resolved this on wednesday?
Doug: Use a MUST: "While the WS-Transfer operations MUST not exposed in an endpoint's WSDL"
Dave: This is not core to 6721.
... I am fine with the text as it is. I suggest using a separate issue to revisit or make adjustments to previous resolutions.
... I am not too particularly attached to one particular manifestation.
Martin: I don't like the word 'version'.
Delete "Own verion of the" phrase.
No objections to Martin's change.
Doug: I don't agree that changing the
first paragraph should be handled via a separate issue.
... I think it is in the spirit of the earlier resolutions.
Bob: We agreed to the resolution to
6694 irrespective of the various (mis)interpretations.
... If people have an issue with the agreed to text for 6694 let us reopen that issue.
... I suggest that we do NOT elaborate on teh 6694 any further since it is not central to issue 6721.
Asir: The second paragraph in section 7 is not central to 6721.
Bob: Is there any objection to agreeing to just the part below.
Proposed text/extract: "an endpoint MAY choose to expose its own version of the WS-Transfer WSDL by using the following WS-MetadataExchange Dialect URI:"
"This version of the WS-Transfer WSDL can be annotated to indicate any endpoint specific metadata that might be needed by clients interacting with this service. For example, the WSDL MAY have policy assertions to indicate that a certain security algorithm is needed to use the WS-Transfer operations."
Dave: There is need to clarify about dialects.
Doug: One or more WSDL need to be considered.
Bob: Does the above text work for every one?
<Yves> annotating... meaning SAWSDL?
<gpilz> suggests - s/indicate that a certain security algorithm is needed to use the WS-Transfer operations./indicate that a particular security mechanism is used to protect the WS-Transfer operations for this endpoint./
No objections to the amendment from Gil noted above.
Doug to post a new doc with some revisions:
<Wu> how about s/is used to protect /for/ the WS-Transfer ...
The proposed resolution will appy to all specifications except MEX. Specifically, resolution applies only to Transfer, Enumeration, Eventing specs.
This also applies to MEX.
<Bob> proposal is (i.e. retrievable by using a WS-MetadataExchange GetMetadata with a Dialect URI of http://schemas.xmlsoap.org/wsdl/). An endpoint MAY choose to expose the WS-Transfer WSDL by using the following WS-MetadataExchange Dialect:
<Bob> Dialect URI @Identifier value
<Bob> http://www.w3.org/2009/02/ws-tra/TransferWSDL Not defined
<Bob> The WS-Transfer WSDL can be annotated to indicate any endpoint specific metadata that might be needed by clients interacting with this service. For example, the WSDL MAY have policy assertions that indicate a particular security mechanism used to protect the WS-Transfer operations supported by this endpoint.
The latest modified version of the proposal in above.
No objections to the above proposed resolution.
Issue 6721 is resolved.
RESOLUTION: 6721 is represented by comment #6 in bugzilla.
No objections to closing 7013 with no action.
RESOLUTION: 7013 closed with no action.
Concrete proposal is at http://www.w3.org/Bugs/Public/attachment.cgi?id=762
s/concrete proposal/concrete manifestion of proposal/
s/concrete manifestation of proposal/concrete manifestation of resolution/
<Yves> optional but mandatory features looks weird
Bob: Any objections to the concrete manifestation of the resolution?
We will revisit this after lunch.
<dug> eventing: http://www.w3.org/Bugs/Public/attachment.cgi?id=765
We are continuing to look for changes made by the editor relating to correctly describing optional elements/features.
Wu has a question about making fault reason as optional.
Wu is satisfied with the explanation.
<Bob> scribe: Gilbert Pilz
<Bob> scribenick: gpilz
Bob: has everyone considered the
... does anyone need more time?
Asir: it's not very clear what is
optional and what is not
... maybe we need to do a little homework before accepting such a global statement
Kary: concern is with optional operations
Asir: suggest we do more homework and be ready to discuss next meeting
<scribe> ACTION: Ram and Katy review latest text for 7207 and determine whether there is any ambiguity [recorded in http://www.w3.org/2009/10/02-ws-ra-minutes.html#action01]
<trackbot> Created ACTION-117 - And Katy review latest text for 7207 and determine whether there is any ambiguity [on Ram Jeyaraman - due 2009-10-09].
Bob: there is a proposed resolution
DaveS: describes proposal
Martin: seems bloated - having to have 3 time values to specify an expiration
DaveS: "exact" seems to be a minority case
Martin: most programming uses exact times - hints etc. are the exception
<Yves> +1 to differentiate hints and non-hints
Gil: would like to flip hint and non-hint syntax
Daves: taking away default values
makes the whole thing more complicated
... right now, with a default min=0 and a default max=infinity, things always make sense
Doug: it depends upon your point of
... for example, what happens if I include a min attribute, but no max attribute
Wu: like this proposal
<Yves> Dave's proposal, using attribute to give multiple non-hints and value for the hint (one target) seems optimal
Wu: if it's difficult to support "any" because of schema, don't do it (no one seemed to care about any)
Ram: I like the proposal
<Bob> Chair notes that a +1 would suffice
<Yves> gil, the client might always trash or not process things that are not getting back within the wanted range
<Yves> (if @min and @max are not supported)
Gil: need faults etc. to handle "wrong" cases
yves: that's just how we got here in the first place . . . we wanted something better than Subscribe, check SubscribeResponse, Unsubscribe
Asir: some question whether empty tag
can be specified for "any" case
... all we have to say is 'nillable="true"'
(some discussion about how nillable works, difference between empty tag and xsi:Null
<Yves> nillable optional elements... oh joy :)
Martin: there's a big deal being made
about replicating current behavior
... is there agreement about what the current behavior actually is?
Doug: what is the fault for when the three values are hosed?
(all) some sender fault
Doug: we need an exact fault
<asir> For folks who would like to understand how to use nillable and xsi:nil, please see IBM/David Fallside's excellent documentation, http://www.w3.org/TR/xmlschema-0/#Nils
Doug: why nillable is not appropriate
Bob: is anybody speaking against this general approach?
Katy: the problem is not with the number of characters, it's the processing involved with comparing three values
<Yves> <Expires @exact=1h>1h</Expires> ?
Katy: we need a shorthand that means "exact"
Yves: it's not checking the number of characters, it's comparing three values
think about 3 xs:dateTimes each with different timezones
<Bob> Yves, Touche
compare all three and figure out if they are the same
<dug> still shorter than a 1 gig xml file
<Yves> gil, see proposal above ot have an @exact as a shorthand for @min @max
<asir> Yep .. XML Schema says that you normalize dateTime and then compare
<asir> ordering is defined in XML Schema
Bob: can we agree to provide a shorthand for exact?
<Katy> How about <Expires @exact>1h</Expires> ?
Wu: seems to make sense
<asir> if you are using a schema library, you don't have to do anything
<MartinC> +1 to katy
Daves: don't think a shorthand is necessary
Bob: (repeating) can we agree to provide a shorthand for exact?
Ram: Katy, I think your concern is all the extra processing of comparing three values
Katy: it's not a make or break thing
Bob: is it acceptable to leave it as it is
Katy: if no one else cares, I'm willing to bend
Bob: anyone else care?
Doug: I do, I'd like to make the obvious case as easy as possible
<MartinC> revesre it to <expires non-exact> 1hr </expires>
<Yves> so by default you expect that all clocks are synchronized perfectly?
Bob: add the @exact attribute to the proposal - "@exact is shorthand for min, max, and value all being equal"
<Ashok> Default ?
it already exits in the spec
<Ashok> INF is defined in XML Schema
If this attribute value is "true" the @min and @max attributes MUST be ignored and the wse:Expires element evaluated as if @min, @max, and the value of wse:Expires had identical values.
<Yves> sounds good
<DaveS> The default value is "false" in which case this attribute has no effect. If this attribute value is "true" both @min and @max attributes MUST be ignored and are assumed to have the same value as the wse:Expires element.
If the wse:Expires element in not present and the event source is not able to grant an indefinite subscription, it MUST generate a wse:ExpirationTimeExceeded fault.
this has to go away : If the wse:Expires element in not present and the event source is not able to grant an indefinite subscription, it MUST generate a wse:ExpirationTimeExceeded fault.
<asir> can use the same 'Expires' tag by disallowing min, max and exact attributes in a *Response
<Yves> well why would those occur in a response?
<asir> they won't
<Yves> and at worst if they occur in a response it will be ignored
<DaveS> Need a new response type wse:GrantedExpires
<DaveS> (xs:dateTime | xs:duration)
<DaveS> </wse:GrantedExpires> ?
<DaveS> The value of this element indicates the expiration time (or duration) granted by the event source. If this element is missing the expires time is indefinite.
<Wu> If expir element is missing, min=0, max=inf, expir=inf?
<Wu> In other words, they all take their default value
(all): discuss the use of a new GrantedExpires element in the SubscribeResponse
<Ram> The <GrantedExpires> must have the same schema type definition as the existing <Expires>
Li: would like Event Source to provide policy for min and max supported expiration times
Ram: what about Renew operation?
... exact same semantics?
(all): must be identical
RESOLUTION: comment #4
resolves 7478 - also applies to Renew
... apply the same resolution to Enumeration Issue 7587
Complete notes: 7586 and 7588 were addressed yesterday (action to develop proposal that includes the use of both dateTime and duration)
Doug: discusses mixing data types of @min, @max and Expires
RESOLUTION: 6407 resolved as proposed
note with the standard policy yadda, yadda stuff added
<Katy> 7553 and 7554 Proposal here http://www.w3.org/Bugs/Public/attachment.cgi?id=769
<Katy> A registration of interest in receiving Notification messages from an
<Katy> Event Source. Subscriptions may be created, renewed, expired or
<Katy> If the subscription is not active, the request MUST fail and the subscription manager MAY generate a wse:UnknownSubscription fault.
<Bob> 7554 was consolidated with 7553
Katy: (explains proposal)
<Katy> A registration of interest in receiving Notification messages from an
<Katy> Event Source. Subscriptions may be created, renewed, expired or
<Katy> cancelled. A Subscription is active when it has been created but has not been expired or cancelled.
<Katy> If the subscription manager chooses not to renew this subscription, the request MUST fail, and the subscription manager MUST generate a SOAP 1.1 fault or a SOAP 1.2 Receiver fault indicating that the renewal was not accepted.
<li> yes, soap 1.1 fault => soap 1.1 Server fault
<li> soap 1.1 Server == soap 1.2 Receiver
<Katy> The following element MAY be used to convey additional information in the the detail element of a SOAP 1.1 fault or a SOAP 1.2 receiver fault.
Doug: The following element MAY be used to convey additional information in the detail element of a fault.
Bob: Any objections to resolving 7553, 7554 with above
Wu: Would like more time
Bob: Meeting of 10/06 is
... Next concall will be 10/13/2009
... The WG Thanks IBM which has graciously hosted this meeting as also thanks Katy and Paul for arranging the entertainment Wednesday Night