See also: IRC log
<trackbot> Date: 06 August 2009
<Bob> scribe: Ashok Malhotra
<Ashok> scribenick: Ashok
Bob: Letting eventing have a bit of a rest ... awaiting AIs
Doug: No way to create metedata
in MEX
... MEX lets you access and manipulate metadata but not create
it.
<scribe> ... new operation createMetadata
UNKNOWN_SPEAKER: adds to or overrides existing metadata
Geoff: Not clear we have a
usecase for creating metadata
... and then we will add delete?
... we are adding Transfer operations to MEX
... two ways of doing the same thing
... concerned about adding operations to service endpoint
... security considerations
... we may need a separate endpoint
... is this really necessary?
Gil: Think abt a management tool
Geoff: Don't think this meets the 80/20 cut ... security is a considertation
Bob: Are you arguing for CNA?
Geoff: I'm struggling to see the usecase
Dug: If you can get metadata why
not allow update?
... security is always a concern
... there is no way to create metadata. Transfer create is
different
... there is no duplication
Asir: Dug wants to know how you
associate metadata created with the endpoint
... the service will make the association
... if I allow others to create metadata for me I will provide
a metadata resource factory
... and use transfer create on it.
Dug: Where is that defined?
... there is no notion of a metadata factory
Asir: We can add wording re. metadata resource factory
<Tom_Rutt> dug wants creation of metadata and linking it to an endpoint to be dedfined in this spec, while asir wants it to be outside the scope
<Yves> metadata is not data?
Dug: Metadata factory is not the right solution
Tom: How do you expose the factory in a std way?
Dug: How do I get the factory?
Asir: Out of band
Dug: My proposal makes it part of the standard ... in band
Gil: Where is this factory discussed
Asir: Section 4 of Transfer
Gil: There are a lot of dotted lines
Geoff: Reminds us of implict
operations. We would be adding another implicit operation
... this has side effects
... separate EPR provides security
Dug: Not the same as a Transfer
create
... Transfer create creates a brand new resource
... my usecase associates metadata with an existing
resource
Bob: Would a Transfer PUT do it
for you?
... you are looking for an in band solution
Dug: Could work if PUT was decorated with appropriate flags
<asir> As always, a service endpoint can be a metadata resource, metadata resource factory, etc.
Bob: If we provided handles to the factory would that be sufficient
Asir: optional handles
Gil: I go to the Endpoint, gate the factory EPR then do a Transfer PUT on that
Dug: I want to see the details
Bob: Consider a proposal where we have an operation to get Metadata factory
<Yves> always the same issue, link between resource and metadata on the resource. sharing the same URI or EPR is a solution, as it creates an implicit link, but it's suboptimal exactly because of the conflicts of verbs used to manipulate resource and the metadata
Gil: I want to see the proposal
Dug agrees to write a new proposal along these lines. Extend MEX to add operations to get appropriate EPRs
<DaveS> 1) Resource is: www.res
<DaveS> 2) The metedata EPR is: www.res.meta
<DaveS> 3) There is also a factory EPR: www.res.metafactory
<DaveS> 4) To create a meta data at www.res.meta I send a T-Create to www.res.metafactory with args (www.res, www.res.meta, metadata).
Asir: That's how it works today
Dug: It is not defined
Asir: We can add more words
Dave: I want to see the proposal
Asir: I am not aware of any
implementations of GET METADATA method
... who would implement such a method
... they always have another EPR
Dave: That's a separate issue
Asir: If we add these operations who will implement?
Dug/Bob: That's premature
Bob: Agreement on direction. Add operations to MEX to expose factory EPR so that TRANSFER optional operation may be used on the factory EPR to create/modify metadata
Asir: There ia a single operation on factory ... CREATE
Dug: May also allow PUT
<asir> As always, a service endpoint can be a metadata resource, metadata resource factory, etc.
<dug> Add optional operation to mex to expose factory EPR so that Transfer operations (e.g. create, put) may be used on the factory EPR to create/modify metadata.
<asir> Asir: need to wait for a proposal
Bob: The above is a directional resolution to issue 6411. Dug will create proposal along these lines.
Bob: make RFC 3986 a normative
reference esp. Section 6.2 that defines comparison or
URIs
... 6.2.1 defines the simplest case --- string comparison
... Resolve by adding the above as normative reference
<dug> MUST use RFC3986 section 6.2.1 for the comparison
<Bob> URI comparisons are performed according to RFC3986 section 6.2.1
RESOLUTION: Issue 7194 resolved by adding "URI comparisons are performed according to RFC3986 section 6.2.1" and adding normative reference
BREAK for 15 minutes
RESUMING after BREAK
<Bob> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6679
Gil: Is the text in Bugzilla
accurate? If so, we should add it
... Add text as 3rd para to section 5
<dug> When the metadata for an endpoint is not available or is unknown and there is no information on how to retrieve it (e.g. an endpoint reference to a [WS-Transfer] resource representing the metadata), a requester MAY send a Get Metadata request message to that endpoint to retrieve its metadata.
<dug> To retrieve metadata about an endpoint, a requester MAY send a GetMetadata request message to the endpoint to retrieve its metadata.
<dug> To retrieve metadata about an endpoint, a requester MAY send a GetMetadata request message to the endpoint to retrieve metadata about the endpoint.
<dug> A requester MAY send a GetMetadata request message to the endpoint to retrieve metadata about the endpoint.
<gpilz> To retrieve metadata about an endpoint, a requester MAY send a GetMetadata request message to the endpoint to retrieve the metadata associated with the endpoint.
<gpilz> A requester MAY send a GetMetadata request message to the endpoint to retrieve the metadata associated with the endpoint.
<dug> A requester MAY send a GetMetadata request message to an endpoint to retrieve the metadata associated with that endpoint.
RESOLUTION: Issue 6679 resolved with wording in Comment #1 in Bugzilla
Dug: Can we skip this one for now ...
Bob: I will connect to implicit
operations issue
... 6694
<Bob> http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Jul/0085.html
Asir: High-level proposal is at
http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Jul/0085.html
... creates a WS-Policy assertion for filter dialects in
Enum
... has Endpoint scope
... can specify multiple dialects supported
... if people agree we can use this as a template to create
further assetions
Wu: We needf namespace to put the assertions
Geoff: What about optional
operations?
... how would they be represented in policy?
Asir: We need to look at
that
... on a case-by-case basis
Dug: We need to consider how easy
or hard we want policy interesection to be
... these proposals require domain-specific logic for
intersection
Wu: Asks abt domian-specific logic
Dug: This assertion is specific to enum.
Gil: Explains use of assertion
Asir: We shd try and avoid
domain-specific processing.
... Shd the dialect be parameter or nested assertion
... nested assertion with QNames for each dialect would allow
domain independent processing
<dug> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6403
Gil: Discusses use of optional on the filter dialect ... use case to test only if enum is supported or not
Dug: My proposal uses nested assertion and uses non domian-specific logic
Wu: Combine assertions into one
Asir: Let's avoid talking abt domain-specific because it is complicated
Straw poll: We need to match on filter dialects
scribe: also strong preference to aviod domian-spefic processing
Dug: we need to be abls to says
1. Enum supported or not
2. What features supported
<Yves> if you go the route of describing all the capabilities, then you will end up with a lengthy one and not usable in implementations anyway
3. Nested vs. siblings
<Yves> (like Accept: headers in http to list all the mime types, but even worse :) )
3 (amended) support clients who do not care about the features
Asir: Put assertions in namespace owned by this WG
Gil: But I can define by own dialect in my namespace
Dug: We already poach on other namespaces e.g. XPath
Dave: If we define it we shd own it
Asir: QNames for assertions we define shd be in our namespace
<Bob> 1. Enum supported or not
<Bob> 2. What features supported
<Bob> 3 support clients who do not care about the features
<Bob> 4. QNames for assertions we define shoud be in our namespace
Wu: Do we have one namespace or one per document
<Bob> 5. assertions shall be concrete
Directional decision to create proposal based on above 5 principles.
<scribe> ACTION: Dug and Asir to prepare proposal for issue 6403 [recorded in http://www.w3.org/2009/08/06-ws-ra-minutes.html#action01]
<trackbot> Created ACTION-90 - And Asir to prepare proposal for issue 6403 [on Doug Davis - due 2009-08-13].
<dug> If the oversize item is the last item to be returned for this enumeration
<dug> context and the data source skips it, it MUST include the wsen:EndOfSequence
<dug> item in the Pull response and invalidate the enumeration context; that is, it
<dug> may not return zero items but not consider the enumeration completed.
<dug> http://www.w3.org/2002/ws/ra/edcopies/wsenum.html
Dug: Erase text after ; ?
Geoff: Have to be careful when
invalidating enum context
... thats what the end of the sentence is saying
... clarifies client and servers versions of the enum
context
<Bob> proposed: strike"; that is, it may not return zero items but not consider the enumeration completed. See the discussion of wsen:EndOfSequence below"
<Bob> and . s/oversized/oversized
RESOLUTION: Issue 7192 resolved with above resolution
BREAK fot 1 hour ... return at 12:42
<asir> Scribe: Asir S Vedamuthu
<asir> ScribeNick: asir
<scribe> ACTION: Wu (and Ashok) to prep infoset proposals for all the WS-RA specs [recorded in http://www.w3.org/2009/08/06-ws-ra-minutes.html#action02]
<trackbot> Created ACTION-91 - (and Ashok) to prep infoset proposals for all the WS-RA specs [on wu chou - due 2009-08-13].
Bob: these should not introduce
any functional changes
... okay to process this work post-Last Call
Issues - 6568-6572
<scribe> ACTION: Ram to prep concrete proposals for issues 6568-6572 (due - 4 weeks before last call or Hursley F2F) [recorded in http://www.w3.org/2009/08/06-ws-ra-minutes.html#action03]
<trackbot> Created ACTION-92 - Prep concrete proposals for issues 6568-6572 (due - 4 weeks before last call or Hursley F2F) [on Ram Jeyaraman - due 2009-08-13].
Bob: please review these proposals before the August 18th meeting
<Ram> ACTION: Ram to check the latest drafts including RFC 2119 terms. [recorded in http://www.w3.org/2009/08/06-ws-ra-minutes.html#action04]
<trackbot> Created ACTION-93 - Check the latest drafts including RFC 2119 terms. [on Ram Jeyaraman - due 2009-08-13].
Bob: these are pending decision
on ws-fragment
... what is the impact of WS-Fragment on RT
Doug: have not done any analysis
<Zakim> asir, you wanted to talk about infosets
Asir: concerned about the amount of work on infosets
Bob: classify infoset related issues as Last Call issues
Returning to RT issues ...
Geoff: can Doug and Ram articulate what RT issues are related to WS-Frag and what remaining issues are related to RT
<scribe> ACTION: Ram to review RT issues and re-classify the targets - WS-Frag | RT | Moot [recorded in http://www.w3.org/2009/08/06-ws-ra-minutes.html#action05]
<trackbot> Created ACTION-94 - Review RT issues and re-classify the targets - WS-Frag | RT | Moot [on Ram Jeyaraman - due 2009-08-13].
[Conspiracy to assign all PM actions to Ram :-)]
Agreed to defer this issue to the next F2F
Geoff: add a new fault to indicate that the result is too large
Bob: too large, whose point of view (sender | requestor | etc)
Geoff: too large for the receiver to handle
Doug: is this for all the Transfer operations?
<dug> code, subcode,reason
Doug: if the group can agree on
the three bits - code, subcode and reason, then I can take a
stab at this
... ResultTooLarge
[discussing whose fault this is ...]
sender fault?
Asir: result is not a keyword in transfer
silence
MessageTooLarge
Receiver
code=Receiver
ResponseTooLarge
Applies to Get, Put and Create operations
<Yves> every method returning something might generate that. Even delete (as the limit might be different than from get or put)
May apply to any SOAP message
Proposal: CWNA
Resolution: closed issue 6632 with no action
this issue is superceded by 6401
Proposal - superceded by the direction that the WG agreed for 6401
Resolution: superceded by the direction that the WG agreed for 6401 - closed issue 6401
Tom prefers to keep it open
Applies to put and create
Doug: may be implementation detail
Dave: do you get into trouble for omiting the namespace
Bob: who would figure that out:
Transfer or a resource?
... could be server based implementation
emerging proposal - cwna - head in the sand
Resolution: closed issue 6633 with no action
emerging proposal - cwna
Transfer/@dialect attribute accomodates the use case
Resolution: close 6675 without any action
Gil: workload is smaller than the RM work\
client-side, server-side, etc. kind of discussion in-progress
asir: from a timing point of
view, this could be done during LC
... from a readability point of view, this could be a great
piece of work in the primer
Bob: agrees on timing
... prefer to see in the spec
<jeffm> +q
jeff: agrees with Jeff
Wu: perhaps, in an appendix
Asir: when can we see these drafts
Gil: second week of September
Gil agrees to produce state tables in the second week of September
<scribe> ACTION: Gil to draft state tables for Eventing and Enumeration no later than the second week of September [recorded in http://www.w3.org/2009/08/06-ws-ra-minutes.html#action06]
<trackbot> Sorry, couldn't find user - Gil
<scribe> ACTION: Gilbert to draft state tables for Eventing and Enumeration no later than the second week of September [recorded in http://www.w3.org/2009/08/06-ws-ra-minutes.html#action07]
<trackbot> Created ACTION-95 - Draft state tables for Eventing and Enumeration no later than the second week of September [on Gilbert Pilz - due 2009-08-13].
Need both clien-side and server-side state tables
Bob: close 6635 without any
action?
... resources are in the eyes of the beholder
Resolution: close 6635 without any action
Dave S introduced a proposal
Geoff: can someone define 'application developers'
Doug: we don't have to decide what role
Wu: this is confusing .. who is an app dev or inf dev, they could play both
<Bob> acl li
<Yves> warnings like that may be primer material
+1 to Yves
<Yves> but we should also add "thou shall not write bugs"
<Bob> /me ;-)
<Wu> A web service standard should not impose implementation preference in nomartive specs to enforce one implementation against another
Gil: both parties use policy
assertions
... then everyone is happy
... say someone is using a primitive stack
... they don't have support for policy or policy
assertions
... what does it mean to say I support eventing?
wu: use policy assertion to
indicate that you are using implicit operations
... should not constrain implementations
<jeffm> +q
<Wu> +1 asir
li: interop is at the message level, wsdl to bootstrap
jeff: forgot
<jeffm> +q
<jeffm> i remember now ;-)
dave: want some means to not see implicit operations
<li> 1) there must be a way for a service to expose its wse wsdl
<li> 2) two different wsdls creates interoperability issues
<gpilz> what do you want if you don't have policy?
geoff: want to understand the issue on the tooling side
<gpilz> w/out policy any indication of support infrastructure is an out-of-band assertion
<Yves> a good tool would ignore things in WSDL if they ever appear
<gpilz> considering that the actual name of the operation is not significant - what do I look for?
or as I explained .. if an assertion is used then ops would never show up in a wsdl
<Yves> the time used to discuss that issue is far more that what is needed to code ignoring things in WSDL in available tools
+2 to yves
<Bob> +1 to yves
<li> gil can write you a xslt in no time to remove implicit operations
<gpilz> only if you agree to name them exactly the way they occur in the spec
<dug> not this year - he already wrote one this year
jeff: what are you defending against
<gpilz> not next year either
<gpilz> 1 every 2 years
<Wu> +1 yves
Ram: is there any reason why we are prohibiting app dev to not use wsdls
Bob: one man's infrastructureis another man's app
<Yves> also if you have a MUST NOT, and it's not respected by the other party, what should we do? (ie: let's not define universal error-recovery mechanisms here)
<gpilz> if you violate the MUST NOT you have put yourself outside of our spec
<gpilz> and we can't make any promises about what may or may not happen
<gpilz> it may work - it may not
<gpilz> but its not our problem
<Yves> right it's not our problem, with or without that text
Ram: folks may want to use stacks and may implement their own eventing stack
<gpilz> if we don't say MUST NOT, then we have to address what happens in our spec
Bob: can we agree that if we use a ws-ra policy assertion then we can claim what operations are supported
<Bob> How about: When WS-RA behavior is indicated by the use of policy assertion(s) then WS-RA operations have been implicitly defined.?
Agree with Gil and Wu that this is product documentation
<Wu> There is no interoperable issue without forcing all operations to be implicit, because either it decorated by WS-Policy or through your platform documentation.
yep
Bob: got to specify things that are testable and interoperable
[Recessed for 15 minutes]
<li> the only way to increase interop at message level is to use the same wsdl
<gpilz> define "the same wsdl"
Bob: hear that some folks say
that this is an interop issue and some that this is not an
interop issue
... suggest that if this is an interop issue then demonstrate
that
Gil: which spec to use to demo
Bob: use one of ws-ra specs
... if you were to use anotehr spec then it is a step away from
WS-RA deliverables
Asir: suggest that we use ws-ra specs
Bob: use ws-ra specs
Bob: Aug 24th - will be
away
... 24th is still tentative for Bob
... asks Yves to chair the call
Yves: if available yes
Bob: if not, the Aug 24th call will be cancelled
Setting expectations .. Aug 18th
2119 issues
6568-6572 (before the sep F2F)
[ai walk through ...]
6401 for the next con call
WS-Fragment - Doug and Ram will try their best to have it for the next call
Bob: thanks for the lovely facility, for supporting the wg, for the lovely breakfast and lunch ...
Round of applause
<li> any leftover?
<li> bye
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/wait/way/ Succeeded: s/matadata/metadata/ Succeeded: s/facatory/factory/ Succeeded: s/theis/this/ Succeeded: s/operations/optional operation/ Succeeded: s/6.2.2/6.2.1/ Succeeded: s/By/But/ Succeeded: s/Ersae/Erase/ Succeeded: s/prosed/proposed/ Succeeded: s/oversise/oversized/ Succeeded: s/7015/6632/ Succeeded: s/issue 7127/Topic: 7127/ Succeeded: s/close/closed/ Succeeded: s/ack gil// Succeeded: s/+2/+2 to yves/ Found Scribe: Ashok Malhotra Found ScribeNick: Ashok Found Scribe: Asir S Vedamuthu Found ScribeNick: asir Scribes: Ashok Malhotra, Asir S Vedamuthu ScribeNicks: Ashok, asir Default Present: [Microsoft], li, Yves, Vikas Present: [Microsoft] li Yves Vikas Agenda: http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Aug/0028.html WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 06 Aug 2009 Guessing minutes URL: http://www.w3.org/2009/08/06-ws-ra-minutes.html People with action items: ashok asir dug gil gilbert ram wu[End of scribe.perl diagnostic output]