See also: IRC log
Asir: Use CVS notification for a checkin...to review.
<dug> for some reason why cvs won't send in my cvs update comments
<Yves> also I can make a snapshot at a specific location, easy to do
<dug> well, just doing a cvs diff by date works too
Asir: Use CVS labels and compute automatic diff.
<Yves> yes, we could do a "make snapshot" "make tags" etc...
<asir> what about a diff version
Bob: make a snapshot once a
month.
... Asir help the editors to compute the diffs
<Yves> there should be a diffspec.xsl as well
<Yves> http://lists.w3.org/Archives/Public/public-ws-resource-access-notifications/ is indeed only for bugzilla now, I can make it extended to add cvs commits
<scribe> ACTION: Yves notification setups [recorded in http://www.w3.org/2009/03/11-ws-ra-minutes.html#action02]
<trackbot> Created ACTION-38 - Notification setups [on Yves Lafon - due 2009-03-18].
The working group agrees to monthly review of snapshots.
Asir: Suggested to have summary of change logged at bottom of spec.
Resolution: Add change log at bottom of each spec.
Bob: Executive summary of changes log for public?
Dug: Who will maintain it?
Bob: Look into the executive
summary option later.
... First snapshot review - April 1st
Resolution: First snapshot review - April 1st.
<Bob> Revisit 6400 due to request for overnight review
<Bob> proposal at http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Mar/0051.html
Li: Change subscription & port to Subscription & Porttype.
<li> change SubscriptionEndPort to SubscriptionEndPortType
Resolution: Resolve 6400 by changeing SubscriptionEndPort to SubscriptionEndPortType in the previous tentative resolution
Geoff: Proposed close with no action
Dug: Want to keep GetMetadataResponse for consistency across spec.
<li> EndTo endpoint cannot use wrap interface to receive SubscriptionEnd message because it is a protocol message, not an event message
<dug> <mex:GetMetadataResponse ...>
<dug> <mex:MetadataSection...> ... </mex:MetadataSection> *
<dug> xs:any *
<dug> </mex:GetMetadataResponse>
<Bob> For minutes edit, move Li's comment above start of issue-6500 discussion
Alternative proposal by Dug above
<Bob> It was noted that extensibility is already in the schema, but not in the text
<Bob> Dug: In that case it gets down to just re-naming the element
DaveS, Asir asking for use cases.
<Bob> Dave: What are the use-cases for extending the response?
Katy: Don't rename mex:metadata.
<dug> Katy: go back to original proposal
Bob: Any objection to the proposal.
Geoff: Object, 6398 need to be looked at first.
Gil: No need to add dependency on 6398.
Bob: Any objection to the new proposal?
Geoff, Asir object, asking for more time
Doug Ashok : How much time is required.
Dug: Agains adding dependency of 6398 in 6500.
Gil: Time line to put forward formal objection for 6398?
Bob: Will look at 6500 later.
<Katy> proposal at http://www.soaphub.org/public/files/w3c/t-rt-merge-v2.doc
<Yves> why defining Dialect as an attribute and not as a child element of wst:GET ?
<dug> yves - could be done that way - but there some concern from MSFT folks when we first worked on that they wanted to be able to detect an unknown dialect asap and an attribute was easier than going down one level.
<Yves> dug - what is the namespace of Dialect attribute then? having a wstr:dialect element sounds easier as an extension point than adding an attribute in wst: everytime you want to do such add-on
<dug> well, since we believe that RT will be fundamental to T's use it makes sense to have it part of the same namespace
Geoff: Why are we doing it, as of now there are no issues raised regarding WS-Transfer and WS-RT complexity.
Dug: WS-RT only makes sense in presence of WS-Transfer.
<Bob> Dug argues (amongst other things), that RT reduces the need for transactional support, since it would reduce collisions
<Bob> Dave: If they were written together then the inconsistencies would be resolved, but then ought to be split
<DaveS> 1) Generally splitting is better.
<DaveS> But:
<DaveS> 2) Consistency is needed between T and RT. Merging will fix these.
<DaveS> 3) Prevention of rouge extensions that duplicate RT function.
<DaveS> 4) Interaction semantics between the two capabilities is more transparent.
<DaveS> 5) Encourage wider uptake of the full capability of T + RT.
<DaveS> - Develop together and the split
<DaveS> - Restrict transfer as we split them so as to capture semantic interaction,
<Zakim> asir, you wanted to talk about the history
<Wu> "<DaveS> - Develop together and the split" - Do you mean "Develop together and then split"
Asir: -Duplication, overlap, needs to be handled on case-by-case bases.
<DaveS> yes: Develop the specs together to clarify semantics, overlap, common issues. Then split if the result really looks to complex.
Bob: I am against fully merging the two specs since those who do not wish the functionality in RT may want to implement onlt T without the uncertainties of interop problems caused by optionality.
<Katy> Adding to Dave's list above
<Katy> 6) From Editorial and WG point of consolidating proposals across the 2 specs is far easier (wrt time and effort) when they are merged
<Yves> is dialect fragment or conneg?
<dug> http has fragment support
<Bob> http frags are a user agent function
<Zakim> asir, you wanted to respond to Doug
<Zakim> Yves, you wanted to say is dialect fragment or conneg?
<dug> +1 to yves - transfer is missing a ton of http features
<asir> +1 to Yves for using SOAP extensions
<asir> that is what Resource Transfer does today
Katy: IBM has implementation of WS-RT.
<Geoff> +1 to dug for RT not being as mature at T
<dug> bob - I was referring to the http range headers not the user-agent stuff
<Katy> My comment was: we were reluctant to implement rt due to bp compliance issues with the wst base spec
DaveS: Obligation of smooth transpiration for present implementation.
<Yves> if it is a fragment, should it be part of the EPR?
Bob: Important considerations
1 - Common stuff should be commonly defined.
2- RT Fragments, is an extension; is it a common operation; is it an optional feature?
3- Some RT Features have questions, problems, unclear, broken
<Geoff> is the value of doing this work, greater than the amount of work required to achieve it?
Bob: Does the working group consider frags to be an extension?
<scribe> ACTION: Katy produce a document on frag support as an extension. [recorded in http://www.w3.org/2009/03/11-ws-ra-minutes.html#action03]
<trackbot> Created ACTION-39 - Produce a document on frag support as an extension. [on Katy Warr - due 2009-03-18].
<asir> I promised to add my statements on 6413 to the IRC
<asir> here it is
<asir> If there are any overlap between T and RT, those should be identified as separate issues and resolved
<asir> If there are any duplication between T and RT, those should be identified as separate issues and resolved
<asir> If there are any inconsitencies between T and RT, those should eb identified as separate isseus and resolved
<asir> if any of the current RT issues apply to Transfer, the WG will address them across specs
<asir> We acknowledge the 2 possible cases - simple use case and non-simple use case. We have seen umpteen impls of the simple use case and we have plenty of interop evidence. We do not not seen any implementations of the non-simple use case.
<asir> If any of the RT issues (filed by Microsoft) apply to Transfer then the WG would consider that and address it as well. This is similar to how the WG processed 6428 against Eventing whose resolution was applied to all 5 specifications
<asir> Re bunding specs will increase market adoption and interop - this is a myth. Market adopts value not required and optional features. Bundling is not the solution
<asir> Re WS-Man created a domain specific fragment transfer - RT was born in 2006. WS-Man was born in 2002. It is common for a feature to be born in a domain specific way and then promoted in a generic manner at a later date
<asir> RT did not carry the consensus of the authors during its dev and submission (only IBM and Intel submitted, Microsoft and HP did not).
<asir> There wasn't consensus to add RT to the charter ...
<asir> RT frag transfer is an extension of Transfer (from the SOAP Processing Model point of view)
<asir> In order to not burden current dependant specs on Transfer we believe that the extension should be in a separate specification
<Bob> scribe: Katy
Asir: Ashok polinted out may not
get response for tag
... from tag
... Bob suggested waiting until the last call review
... we are concerned about time and following the Tag
discussion
... What we could do is put each issue in bugzilla and consider
proactively addressing each of the issues
... then Bob could take these issues to the tag
... We volunteer to get these issues out and propose draft
resolutions
Ashok: There are 2 issues 1) why
WS use EPRs rather than URIs? What answer should we give?
... 2) We could consider what does a naked HTTP GET on the URI
return?
Gil: Think we should address any issues at LC and not pre-empt
DaveS: Don't want unecessary energy spent on this.
Asir: Understood, concerned about potential blocking issue
Bob: Being prepared is good. I am
hearing mixed discussions regarding how much preemptive work
should be done
... If we use the issue process (this is public and debated and
requires closure before last call).
... These are not proper issues yet- there are other ways to approach
DaveS: We can prepare a document
and discuss at next F2F
... I will work with you on this.
Ashok: Issues in a WG are opened against documents, what would these issues be opened against
Asir: WS-T (2) and WS-RT (1)
Ashok: What could we say here
Asir: We could say: for 1st
issue: This has been considered by the ws-ra working group and
this is what we have decieded (unified voice)
... for 2 propose: SOAP response pattern binding to HTTP
GET
<Yves> see http://www.w3.org/TR/soap12-part2/#soapinhttp
<scribe> ACTION: Asir and DaveS to collaborate on a discussion document about how to proceed [recorded in http://www.w3.org/2009/03/11-ws-ra-minutes.html#action05]
<trackbot> Created ACTION-40 - And DaveS to collaborate on a discussion document about how to proceed [on Asir Vedamuthu - due 2009-03-18].
Dug: Propose same solution that we accepted for WS-Eventing subscription end
<dug> proposal: http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Mar/0054.html
<dug> and change EnumEndPort to EnumEndPortType
Bob: no objects
RESOLUTION: 6399 resolved
<dug> proposal: http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Mar/0055.html
<dug> an amendment: http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Mar/0056.html
Gil: described issue
... Dealing with filters that will never evaluate to true -
event sources should try to indicate this
Geoff: As Doug said, we need to ensure that it is clear that the generation of this fault is only at subscribe time
Wu: Concerned that the client may use this to test what the event source supports - interop issues
Gil: This is for simple situations where the filter is easily understood
<Bob> It is possible for the request to contain a filter that will not evaluate to true for the lifetime of the Subscription. Although this condition cannot be detected for all dialects, implementers are advised to check for it when possible and, in response to the Subscribe request message, OPTIONALLY to a Subscribe request
<Bob> message generate a wse:EmptyFilter fault.
<dug> It is possible for the Subscribe request to contain a filter that will not evaluate to true for the lifetime of the Subscription. Although this condition might not always be detectable, implementers are advised to check for it when possible and, in response to a Subscribe request message, OPTIONALLY, generate a wse:EmptyFilter fault.
Wu: not sure about 'impls advised to check for this'
Gil: It is just advice
Wu: But this is not preferred
Li: I recognise that this is a very annoying situation but it's hard to imagine how implementations could check this - e.g. xpath
Gil: This is intended for filter
dialects with finite values. Just when it's possible. Impls
could do basic checks
... A key thing is to advise subscribers that an extra fault
could be gen'd when it is clear that there will never be
notification messages
Wu: I am concerned with wording still - 'advised' text
<scribe> ACTION: gpilz work with Wu on text for 6595 [recorded in http://www.w3.org/2009/03/11-ws-ra-minutes.html#action07]
<trackbot> Created ACTION-41 - Work with Wu on text for 6595 [on Gilbert Pilz - due 2009-03-18].
Gil: Outlined key aspects.
EventTypemsg in its own schema plus attribute
extensibility
... in wsdl dfn notifyEventMessage has hdr notify verb and body
notify element
... in soap binding hdr part is bound to soaphdr and body bound
to soap body
... Motivation was to put metadata in header. wse:NotifyVerb in
header - tooling will expose this verb as a parameter
... for e.g. msg bus scenario
dug: This proposal splits the
service level data between the body and the headers
... This concerns me and I would like some time to discuss with
implementation teams
... 1 week's delay
Wu: I propose separate this into 2 issues: 1 agree to have standard interface and separate issue of where to put the action
Geoff: Agreeing with Doug again! Would like time to consider also
gpi: we need crisp texts prior to closing this issue, this proposal is just the form
Wu: Let's close what we have decided and separate out a new action in order to deal with the extended proposal
Gil: The current proposal is not complete for incorporating into the document. Would be nice to have text describing when wrapped would be good.
Wu: Explanationary text should be in primer
Gil: reference to format in appendix would help
Wu: we can create text changes
<gpilz> other probs with current text for 6429: (a) text discusses including the "concrete WSDL" in wse:NotifyTo, how is this done?
<scribe> ACTION: Wu to examine current spec and generate new text for group review [recorded in http://www.w3.org/2009/03/11-ws-ra-minutes.html#action08]
<trackbot> Created ACTION-42 - Examine current spec and generate new text for group review [on wu chou - due 2009-03-18].
Li: Could the verb be a ref param?
Gil: No because the notification type is a constant across the lifetime of the subscription
<gpilz> (b) text says "concrete WSDL can be retrieved by the Event Source use WS-MEX" how?
Li: Agree with Wu that we should close this issue and treat the enhancement as a sep one
Li: This is the proposal that treats the format as an element (rather than an attribute)
http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Mar/0053.html
Dug: Would like to see text describing processing order - filter should be on unformated event
Wu: Agreed this is a good comment. Another issue though.
<scribe> ACTION: Dug to open a new issue for this [recorded in http://www.w3.org/2009/03/11-ws-ra-minutes.html#action09]
<trackbot> Created ACTION-43 - Open a new issue for this [on Doug Davis - due 2009-03-18].
Geoff: What if can't support format element
Dug: It is an optional element
that must be understood
... text decribes that the implied value is unwrapped
... must process or send a fault - not just ignore
Asir: It needs adding to migration path
<asir> migrationPathNeeded
<Yves> "The keyword migrationPathNeeded has been added."
<asir> All hail to the power of consensus!
RESOLUTION: 6428 is resolved
Li: Subscribe has authentication
and authorisation costs so overhead if you need to
unsubscribe/resubscribe
... 3 way handshake required
... pause and resume will reduce this cost
Dug: On overflow do you retain
1st 5 or last 5
... for interop should specify
http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Feb/0023.html
Dug: Consider adding a line one way and change it later if required?
Geoff: Do we need to discuss the value of adding pause and resume?
Wu: value of pause and resume is
highlighted in web services roadmap document (item 5)
... We think this is useful. I am sensitive to Geoff's comment
so we could make this an optional feature
Dug: 2 things that should add to
proposal. 1) clarify whether buffering of msgs happens
before/after filtering
... 2) Retain parameter on pause and response. I would prefer
the pause to fail if the request cannot be granted
Geoff: would like time to consider
<asir> perhaps, in another specification
Ashok: This is extra functionality, not fundamental to the core spec
DaveS: If client does not have pause/resubscribe then can it attain same function by unsubscribe/subscribe
<Bob> k
Wu: pause/resume is a short hand so does not break interop (as it's a shorthand for unsub/sub) but retain message number is not shorthand
gpilz: how would I know whether event source supported pause resume?
Dug: policies
Wu: this is optional
More time for decision requested
<scribe> ACTION: Li to address Doug's 3 concerns [recorded in http://www.w3.org/2009/03/11-ws-ra-minutes.html#action10]
<trackbot> Created ACTION-44 - Address Doug's 3 concerns [on Li Li - due 2009-03-18].
http://www.w3.org/Bugs/Public/show_bug.cgi?id=6498
RESOLUTION: 6498 Resolved as defined in proposal (editors update uri name)
Dug: Mex dialect=group of things
that service should return to client to indicate what's needed
for communication
... but what if the service has metadata that the client might
need (but client doesn't know about)
... At extensibility to enable service to add this 'extra'
metadata stuff
... on top of that add 'all' dialect
... then worry about default
Geoff: Our 'whateverdialect' = Doug's Mex dialect
<dug> 'whateva' used to mean "random - even zero"
Geoff: also think that there
should be a just mex dialect
... mex=the mex dialects
... whatever=the mex dialects plus optional extras
... mex=mex defined dialects crucial=mex plus other stuff that
need to talk to service
gpilz: Should rename 'mex'
<gpilz> 'mex' should be renamed 'defined'
gpilz: Confusion is when a bag of dialects is named the same as a dialect itself
<gpilz> from smallest to largest (schema | wsdl | policy | policyAttacment), defined (set of previous), crucial (defined plus sections requester may not know about), all (everything available to the provider)
Dug: The 4 dialects in the metadata spec are fairly arbitrary. Also they can be gotton by separate requests. So the 'mex' (or 'defined') dialects is not much use.
<dug> none = mex = the stuff the services thinks the client needs to talk to it - minimum = tables in mex
<dug> all (new uri) = everything under the sun the client is allowed to see - ie. dialect=*
asir: Interop testing refer to proposal for 6420 (closed as dup of this one). This proposal talks about min
Dave: I like the idea that the
service knows what you need to talk to it
... eg if I don't need policy documents - why would I return
them?
<marklittle> Hi Bob
<Bob> Hi
Dug: There's a difference between returning anything and what's required by the client to talk
<Bob> ?
<Bob> Katy requests time to conferr with the mothership
Katy: Concerned about the overlap
of these dialects - the same information may be passed back in
policy and wsdl dialects - a huge amount of data in
duplicate
... Puts great requirements on service and large data
transfer
<Zakim> asir, you wanted to answer Katy's q
<DaveS> If we had only all and default (meaning what the service thinks the client needs), what interop or migration problems does this raise?
Ashok: Not clear where policy documents should be returned on receipt of policy dialect
Katy: policy and policy attachment dialact not clearly defined
Asir: Policy references give the
link to the policy documents
... policy dialect is not useful on its own but is useful in a
wider exchange
Dug: concerned that we are overengineering and will confuse people
<asir> well .. at the discretion of a provider .. you may or may not return duplicates
Dug: no longer a for-loop service needs to interpret
<asir> other specifications may define these dialects ..
Geoff: Don't let us forget the key issue - the communication bootstrap 'what do I need to talk to you'
<asir> but for the standards that have already sailed and relevant to WS should be specified in this doc
gpilz: just two different things 1) individual dialacts and 2) bootstrap info
bob: we need to write up and
understand
... few primer words to describe expected usage
... (primer like - might be doesn't need to be in primer)
katy: Issue for describing dialect uri's
s/uris/uri's
bob: The critical set is what the provider needs to communicate?
consensus to this.
bob: do we agree that 'all' is useful?
dug: Use case metadata browser
ashok: or another non-specified dialect (e.g. legal)
consensus
bob: is it true that a provider can provide optimisation?
consensus to this.
bob: What about the current 'mex'
which is a subset of all?
... do we need to define this piece called 'mex'?
<asir> that was awesome Bob!
<dug> none==critical, all=all, allow for list of dialects
<Bob> Agreement:
<Bob> no dialect == everything that the provider considers important with the ability to optimize
<Bob> dialect="ALL" == all known metadata with ability to optimize
<Bob> one can specify a dialect list on the getmetaadatarequest
RESOLUTION: issue 6404 resolved
http://www.w3.org/Bugs/Public/show_bug.cgi?id=6418
Geoff: This may no longer be
valid now that we are specifying the format
... But clarifies if the (optional) content is not there, then
the service decides
Dug: Is this a duplicate?
Asir: it's superceded by another issue
RESOLUTION: superceded by 6405, no editorial action required. Issue closed.
http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Mar/0006.html
Yves: Part of semantic alignment between http and transfer. Work out whether you can retry a request
asir: concerned that the contents of the table is not there - i.e. for each operation state what is safe and what is not
<asir> also we need to see the wording from RFC 2616
<Yves> proposal is getting inspiration from http://tools.ietf.org/html/rfc2616#section-9.1
<asir> agree .. suggest that we prep a concrete proposal prior to closing
Dug: clarification required. Yves - is there something in the spec that would lead you to believe that the transfer get is not safe?
Yves: The spec says nothing so it is not clear.
Bob: and proposal was inspired by RFC 2616
Dug: The spec already implies to me that there is no side effects to a get. What is broken?
Yves: Nothing broken, would just like this explicitly stated
<asir> http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Feb/0045.html
Asir: proposal above
<Yves> after a first delete, you may have an error, but in both cases the resource won't be there ;)
<Yves> but it would be abusive to say that the second delete would result in an operation on a resource
<Yves> http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-06#section-7.1
Asir: Should steal 2616 def - Get is idempotent and safe; put and delete are idempotent
<Yves> "A sequence that never has side effects is idempotent, by definition
<Yves> so doing nothing on a second delete is idempotent
<Bob> +1 Yves
Dug: I agree that we should have the table and as an editor would like the whole text so can just cut-and-paste
<scribe> ACTION: Yves to create red-line text for this issue [recorded in http://www.w3.org/2009/03/11-ws-ra-minutes.html#action11]
<trackbot> Created ACTION-45 - Create red-line text for this issue [on Yves Lafon - due 2009-03-18].
<Geoff> thanks everyone, thanks Bob and host IBM, signing off now...
<asir> +1
Geoff and Asir request time to think.
<Bob> short break
<dug> http://www.dannysbarbque.com/html/morrisville.html
http://www.w3.org/Bugs/Public/show_bug.cgi?id=6641
<Ashok> This document is also available in these non-normative formats: XML, XHTML with visible change markup, Independent copy of the schema for schema documents, A schema for built-in datatypes only, in a separate namespace, and Independent copy of the DTD for schema documents. See also translations.
<Ashok> http://www.w3.org/TR/xmlschema-2/
<Yves> http://www.w3.org/2003/Editors/
<Yves> is the best play to find out
Dug: propose namespace still
points to rddl, rddl points to everything, end of spec
reference to xsd is a direct uri
... (as in proposal above)
RESOLUTION: Resolved 6641 as described above