See also: IRC log
<Bob> scribe: Tom Rutt
<Bob> scribenick: TRutt
Bob asked members to watch IRC as it is happening, and if it does not match what they think it should be stating, they should make real time additions/corrections into the irc chat area themselves.
Bob stated that he would allow a one week postponement of a scheduled vote if any member requests an extra week to consider an issue before the vote.
Asir: In our opiniion. Geoff was not given sufficient time to present his full proposal.
<Bob> Minutes of 2009-02-24 http://www.w3.org/2002/ws/ra/9/02/2009-02-24.html
<Geoff> http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Mar/0027.html
Comments made by Geoff relative to edited version of minutes as posted.
Bob: Would Geoff express which of his concerns were not reflected in the edited minutes?
Geoff: We believe that the statement "Will more discussion help the decision?" should have been stated "Will more discussion of Geoff's proposal help the decision?"
The group reviewed the minutes and two (four with the addition of members that added themselves in the irc below) members stated that the context at that point in the discussion was regarding both contributions.
Minutes of 2009-02-24 were accepted by the working group with Geoff Bullen registering his objection in the email referenced above.
<asir> Not several members .. just two members
Minutes March 3,2009
<asir> stated that the context ...
<Bob> http://www.w3.org/2002/ws/ra/9/03/2009-03-03.html
<gpilz> make that 3 (me)
<dug> 4 - ibm too
No objections to approval of the minutes of 2009-03-03
http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Mar/0020.html
Agreed to add three new issues which have arrived since the preparation of the agenda.
Bob summarized the agenda, and asked if there were any requested changes.
Geoff: what about discussions regarding the TAG? We would like that discussion to be in the first two days.
Bob: lets spend a fair amount of
first day on eventing, then move on if not completed on the
second day
... after first day will try to spend some time on each of the
issues.
... on the third day we can focus on the general discussion
items.
TAG discussion agreed to be after lunch first day
Agenda, as modified was accepted by the group.
adding a f2f at the W3C Tech Plenary 2-6 November in Santa Clara; Potential WG meeting 11/2, 3, 5, and 6 (Must respond by March 18)
Yves: this gives us an opportunity to meet with the TAG, if we and they want to do so
No objection to having WG meetings at TPAC in November.
Discussion ensued on how may days of meeting are appropriate for the WG.
Agreed that Bob will ask for two adjacent days for WG meetings at the TPAC in November
Question on action items review.
Bob: I closed all action items which are completed, I suggest all members go thru the open action item list and work to close the ones assigned to themselves.
-Issue-6648 Eventing: define extensibility model for WS-Eventing http://www.w3.org/Bugs/Public/show_bug.cgi?id=6648 -Pilz
Gill agreed to be the Issue owner. No objection to opening this new issue
ID 6661
<Bob> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6661
No objection to opening issue 6661 with Gil as owner.
Id 6666
http://www.w3.org/Bugs/Public/show_bug.cgi?id=6666
No objection to open issue 6666 with Dug as owner.
<Bob> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6661
<Bob> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6672
No objections to open issue 6672 with Dug as owner
http://www.w3.org/Bugs/Public/show_bug.cgi?id=6673
No objections to open issue 6673 with Dug as owner
id 6674
http://www.w3.org/Bugs/Public/show_bug.cgi?id=6674
There is a general issue on updating references.
Agreed that 6674 is a duplicate of the existing general 'review references' issue
Geoff: that is 6570
id 6675
http://www.w3.org/Bugs/Public/show_bug.cgi?id=6675
No objection to open issue 6675 with Gil as owner
id 6674
Id 6676
http://www.w3.org/Bugs/Public/show_bug.cgi?id=6676
No objection to open 6676 with Gil as owner.
<Bob> proposal at http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Mar/0026.html
Wu presented his latest email
Gil: I do not understand the addition of the wsa:To header to the subscription request
Gil: if wsa:To is not present, is the event source given value anonymous?
Wu: yes
Gil: None of this is explained in the text
Wu: we state "The REQUIRED [event source] property provides the value of the WS-Addressing
wsa: To element.
<dug> perhaps a rewording of that line would help?
Gil: is the event source from the point of view of subsriber of the event source?
<dug> The [event source] property provides the value of the OPTIONAL WS-Addressing wsa:To element.
Wu: from the view of a subscription message from subscriber to event source.
<Yves> http://www.w3.org/TR/soap12-part1/#soapenvelope
<Yves> infoset constructs are not hard to read
<dug> Yves - personally I think infoset hurt wsa and soap specs :-)
<Yves> dug; infoset allows things like MTOM and use of other encodings of the envelipe
Asir: we could accept Wu's proposal, with understanding that additional issues can be raised to clarify specific text later
<dug> I understand why they were added - but I think they hurt more than they helped.
<dug> The [event source] property provides the value of the OPTIONAL WS-Addressing wsa:To element.
<asir> I believe that Wu's proposal is a template for global changes
Gil: I like this new wording
<dug> The REQUIRED [event source] property provides the value of the OPTIONAL WS-Addressing wsa:To element.
Wu: this new wording is acceptable, however we have to be careful on cardinality
<gpilz> The wsa:To element is populated by the REQUIRED [event source] property.
Wu: I prefer "provided" to populated
<gpilz> The value of the wsa:To element is provided by the REQUIRED [event source] property.
Dug: maybe we should map the ws
eventing infoset to the appropriate ws addresssing
infoset
... however Event source property would need to get mapped to
destination plus reference properties
<dug> The value of the WS-Addressing [destination] and [ref params] properties is provided by the REQUIRED [event source] property.
Darecussion on the event source as an EPR vs an IRI
gil: however wsa:To is just a uri, but the event source EPR also can include ref parms
<gpilz> gil: and metadata
<Wu> wu
Gil: could have general discussion on ws addressing addressing properties, but don not have text describin the wsa headers. Only discuss wse headers in the text
<Bob> The values of the WS-Addressing [destination] and [ref params] properties are provided by the REQUIRED [event source] property.
replace from /s:Envelope/s:Header/wsa:To The REQUIRED [event source] property provides the value of the WS-Addressing wsa:To element.
Geoff: what about the wsa:Action text in this section
<dug> Geoff - that might be handled by the new issue I opened the other day
Bob: lets first discuss the replacement of the wsa:To line
DaveS: there is no way to
reconstrict event source EPR from the headers in the subscribe
message
... leave this text out say "ws addressing shall populate its
headers as appropriate from the information in the event source
epr"
<Bob> +1 , Li
Li: section 3.3 of ws addressing core text should not be repeated
Li: put reference to ws addressing text
<dug> The [event source] is used as the target endpoint reference of the Subscribe message and is processed per WS-Addressing.
<DaveS> +1 to dug's text
Wu: I like Bob's text change for wsa:To, but suggest we keep the text on wsa:Action
<asir> Dug - alternate to what?
Dug: I intend my new text to replace the wsa:To line in the proposal
Gil: given Action value is a constant for this operation type, why does it need to be mapped to an infoset property?
Wu: infoset properties can be constants, there is no restriction against them having constant value
<dug> its too bad that someone didn't just write an XML->Infoset converter/rules and then we could just keep the spec as XML.
Wu: should the receiver reject the message if the wsa:Action value is incorrect?
<Bob> The [event source] is used as the target endpoint reference of the Subscribe message and is processed per WS-Addressing.
<Yves> dug; by "keep the spec as XML" you mean "easily transform the spec to infoset at publication time, and keep the master as XML" ? :)
Wu: add "REQUIRED" after "The"
<Bob> The REQUIRED [event source] property is used as the target endpoint reference of the Subscribe message and is processed per WS-Addressing.
Agreed to replace the text:
/s:Envelope/s:Header/wsa:To The REQUIRED [event source] property provides the value of the WS-Addressing wsa:To element.
with
The REQUIRED [event source] property is used as the target endpoint reference of the Subscribe message and is processed per WS-Addressing.
No objection to replacement suggested by Bob
Gil: does the action property have type of wsa:action? Is there a type for an infoset property?
<gpilz> [action] : IRI (1..1)
<gpilz> [destination] : IRI (1..1)
<gpilz> [source endpoint] : endpoint reference (0..1)
Text under discussion: "[action]: wsa:[action]"
Bob: we need to review this for correct xml infoset syntax at some time.
<dug> Add this after the previous text we just agreed to: The REQUIRED WS-Eventing [action] property is mapped to the WS-Addressing [action] property.
<dug> hmm, or is the mapping the other way around
Gil: the action is of type "IRI" , however do we need to claim that wse action is always the same value as wsa:action property. Why do we need two properties? There is only one action header in the message.
wu: in the future wse action property value may not map directly to wsa action value
<dug> should it be [action]: http://.../Subscribe
<gpilz> [event source]: endpoint reference (1..1)
Katy: this should be type, not a value
<gpilz> [action]: IRI (1..1)
<dug> [action]: IRI
<dug> Identifies the semantics of this message - and MUST be http://.../Subscribe
Bob: question under discussion is what should be the proper syntax for the line "[action]: wsa:[action]"
Gil: an important question is
whether wse should have its own action property, distinct from
wsa:action property
... I do not believe wse needs its own action property
Li: I believe we should have wse action property, since its infoset needs to be complete on its own. If ws addressing is used, the wse action maps to the wsa action value. We are assigning a different contractual meaning to the two infoset properties.
Katy: The fact that we are using the infoset notation requires that we define an action value for eventing.
<DaveS> This should read [action]: IRI (1,1) which defines the type, and any thing about the value shoud go below
Wu: currently ws eventing is piggybacked on ws addressing. For completeness of modeling it is appropriate to have a property wse action
Dug: the reason we are using
action is because we are using ws addressing. If addressing
later adds a user ID propety would we need to add a new wse
infoset property for this user ID property?
... was action is not really even necessary for wse
... eventing should define the minimum properties it needs
Wu: but it is in the current version of the spec, wse required the action value
Dug: yes addressing requires it, but why should the wse infoset require it?
Gil: I would take out wse:action as an infoset property, is is not an abstract property of ws eventing.
<DaveS> Delete [action] section from the red and grey.
<DaveS> In the white text below:
<DaveS> This property MUST have the valuehttp://schemas.xmlsoap.org/ws/2004/08/eventing/Subscribe
<dug> Gil - mex is now fixed (the ns/enum issue)
<gpilz> This element (a serialization of the WS-Addressing [action] property) MUST have the value "http://schemas.xmlsoap.org/ws/2004/08/eventing/Subscribe"
Li: expressed concerns about being tied too much to ws addressing. Having a separate property for wse is advantageous in my opinion.
Asir: I also prefer to just have the ws addressing property for action
Wu: I can accept the proposal from Dave S, to define use of wsa:action in the xml text itself, and remove the wse infoset property for action.
<Bob> This element (a serialization of the WS-Addressing [action] property) MUST have the value "http://schemas.xmlsoap.org/ws/2004/08/eventing/Subscribe"
above sentence replaces /s:Envelope/s:Header/wsa:Action This REQUIRED element provides the value of the [action] property. If a SOAP Action URI is used in the binding for SOAP, the value indicated herein MUST be used for that URI.
<Bob> in addition action would be removed from the red on grey text
delete wse:action as its own infoset property
<dug> http://www.w3.org/2002/ws/ra/edcopies/wsrt.html#put
replace
/s:Envelope/s:Header/wsa:Action This REQUIRED element provides the value of the [action] property. If a SOAP Action URI is used in the binding for SOAP, the value indicated herein MUST be used for that URI.
with
This element (a serialization of the WS-Addressing [action] property) MUST have the value "http://schemas.xmlsoap.org/ws/2004/08/eventing/Subscribe"
and remove action from wse infoset
<dug> s:Envelope/s:Header/wsa:Action
<dug> This required element MUST contain the value http://www.w3.org/2009/02/ws-tra/Get. If a SOAP Action URI is also present in the underlying transport, its value MUST convey the same value.
replacement text needs to include first line: /s:Envelope/s:Header/wsa:Action This element (a serialization of the WS-Addressing [action] property) MUST have the value "http://schemas.xmlsoap.org/ws/2004/08/eventing/Subscribe"
<dug> http://www.w3.org/2002/ws/ra/edcopies/wsrt.html#put
Replace: /s:Envelope/s:Header/wsa:Action This REQUIRED element provides the value of the [action] property. If a SOAP Action URI is used in the binding for SOAP, the value indicated herein MUST be used for that URI. With: /s:Envelope/s:Header/wsa:Action This element (a serialization of the WS-Addressing [action] property) MUST have the value "http://schemas.xmlsoap.org/ws/2004/08/eventing/Subscribe"
also delete the infoset parameter wse action
<jeffm> i'm just pleased as punch to approve
No objection to proposed change of deletion of infoset property wse action, and replacement of paragraph above
<jeffm> it's swell
Gil: this looks good for ws
eventing, is this proposal just for ws eventiing? what about
the other specs
... I am happy to apply this to ws eventing, I would like to
see a similar set of markup text for the other specs as
well.
Bob: the issue we are discussing is limited to the context of ws eventing.
Bob: we can later open up new issues, one for each of the other specs, to do similar things
Bob: We seem to have agreed to
apply this the same way to all the specs, however we need to
open specific issues for each of the other specs. The
resolution of these new issues will require explicit text for
approval by the WG.
... any general resolution would have to be followed by
explicit text changes for each spec.
Geoff: is there a general agreement on this direction as a general resolution?
Discussion on whether we now have a fully enabling proposal to resolve Issue 6424.
<dug> Either way Wu will probably be doing the work ;-)
Bob: will anyone object to having
the editors apply similar changes as a proposed resolution to
the rest of the eventing spec sections, and also for all the
other specs?
... will anyone object to having the editors apply similar
changes as a proposed resolution to the rest of the eventing
spec sections, and also for all the other specs?
Bob: do we agree that the proposal (version 7) from Wu with the two text changes we approved above can resolve issue 6424?
Resolution: No objection to resolve issue 6424 with the proposal in bugzilla with the two amendments above.
<trackbot> Created ACTION-33 - Will create new issues to apply similar pattern to remainder of eventing spec and each of the other remaining specs. [on Bob Natale - due 2009-03-17].
No objection to apply this pattern to the rest of the ws eventing and the other specs.
Break for lunch
<Bob> scribe: David Snelling
<Bob> scribenick: DaveS
Ashok: The URI is the basis of the WWW. If the URI points to a Document and you do a Get, you get a document. If it point to a thing you get a "representation" of the thing, e.g. a picture of a house. The HTTP link-header form will contain links to metadata about the resource. This might be an approach we could take, e.g. point to the type of data we want about the resource.
<Bob> http://tools.ietf.org/html/draft-nottingham-http-link-header-03
Ashok: Should we consider using this strategy for getting access to metadata about a resource?
Bob: Other actives include SOAP over other protocols. This seems HTTP specific.
This is a generalization of Link_data to Http generally.
Bob: The "Team" comment with
respect to transfer still stands as the supported TAG, e.g. why
not just use URL's? and related issues.
... There are some processing implications: Caching of
representations, proxies, etc. The TAG see these as advantages
vs. what impact they have on our work.
Asir: Is this really important to TAG or should we just proceed?
Bob: The last time the WS-A group followed the public comment process.
Ashok: There was some concern that this working group might not start as a result of this issue. A lot of the problem centers on the EPR.
DaveS: This issue is very old, back to the initial WS-A discussions.
Dug: There isn't much we can do here. The cat is out of the bag sine EPRs.
Asir: Do we need to approach them before?
Bob: We should use this opertunity to plan.
Gil: Not all our specs actually require EPRs. E.g Subscription is all about SOAP.
<Ashok> Link Header draft: http://tools.ietf.org/html/draft-nottingham-http-link-header-03
<gpilz> to ammend the minutes: it is easier to defend the use of EPRs in some of our specs than others because some of them (e.g. WS-Eventing, WS-Enumeration) are more SOAP-oriented than others
Bob: First, the TAG talks about a
lot of possible clients. We are much more SOAP only focused.
These might XMLP related, rather than just http. We also use
"posts" with is not so rest-ful.
... We could provide an "overlay". Define what would happen if
a GET was passed to one of our "resources".
<Yves> SOAP 1.2 uses HTTP GET
<Yves> the state of implementation of this is... not widely deployed
Bob: This would give us the chance to preempt them or we could just wait. We should decide on this.
Dug: Transfer tries to walk a middle ground between http and SOAP. Options are abandon RPs or make a rest-ful equivalent. Similar problems with Mex. We should decide to prempt or not.
Bob: The TAGs concern is not a SOAP issue.
Asir: Tx is http over SOAP (over any soap binding).
<dug> no transfer is not http over soap - otherwise transfer is missing a ton of stuff
Asir: Tx is http over SOAP (over any soap binding)
Gil: Enum and Eventing are very
focused specs. Only ever talked to by soap clients. people
might want to do both with a Tx resource.
... We could describe a way to marshal RPs into ?-parms.
<asir> I think Gil is talking about how to map an EPR to an URI
Bob: we could do this as a WG note.
Yves: RPs are hard to do in ?-parms. There are also other parts of the message (context ext) that would need to be done. This is too much for this WG. We could define it for RP free EPRs.
<dug> +1 to Ashok - w/o a clear issue from someone/tag we're just guess at a solution to an unknown problem
Ashok: If no one wants to look at this, we should just wait.
Asir: The dual use use case is a good one with we might want to address.
Ashok: We can wait or be proactive.
Bob: Does anybody want to work on a proposal in advance of a comment from TAG?
Asir: What about the on going discussin?
Ashok: There is no real outcome from this discussion.
<dug> Why didn't WSA have to answer the question of "what gets returned from a naked GET to an EPR?" ?
Asir: The WG will process any actual comments from TAG.
Bob: WS-A was never asked the question "what comes back" but a more abstract question was asked and answered - accordingly.
Resolution: No one is interested at this time in preparing a premptive proposal.
<dug> 6400 - proposal: http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Mar/0051.html
Discussion and clarification.
Wu: Do we put this new PortType into the spec? How does it change the spec.
Dug: Simply remove some an add a new porttype.
resolved: tentatively accepted.
Li: Does this imply push only semantics?
Gil: It seems ok.
Bob: Postone overnight for
thinking.
... updated bugzilla.
<Bob> Proposal at http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Feb/att-0112/00-part
http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Feb/0024.html
Li: Closely related to the discussion this morning about [event source].
Gil: There seems to be a lot of implicit (indirect) knowledge needed to understand this.
Dug: Is this really about all entities, or just event source, e.g. EndTo, etc.
Gil: They are all EPRs.
<gpilz> wse:NotifyTo, wse:SubscriptionManager, wse:EndTo
Li: We could make it a blanket statement.
Dug: We should do this in all specs. Or borrow text from one of the other specs.
<asir> Transfer Web Service Resource: A resource is a Web service that is addressable by an endpoint reference [WS-Addressing 1.0 Core] and can be represented by an XML Infoset. The resource's representation can be retrieved using the Get operation defined in [WS-Transfer].
Geoff: Doesn't the infoset work cover this?
Wu: Maybe, but would prefer to see it stated explicitly.
<asir> And a metadata resource is defined as ...
<asir> When the representation of a resource is mex:Metadata, as defined in Section 4, or any other document format (e.g. [XML Schema: Structures],[XML Schema: Datatypes], [WSDL 1.1], [WS-Policy]) for which a mex:MetadataSection/@Dialect has been defined, then the resource is referred as 'metadata resource'. The representation of a metadata resource MAY be retrieved and/or updated as any other [WS-Transfer] resource. Specifically, the representation of a metadata resource M
<dug> All messages defined by this specification are sent to a Web service that is addressable by an endpoint reference [WS-Addressing 1.0 Core] and can be represented by an XML Infoset.
<dug> All messages defined by this specification are sent to a Web service that is addressable by an endpoint reference [WS-Addressing 1.0 Core].
<dug> All messages defined by this specification are sent to a Web service that is addressable by an EPR [WS-Addressing 1.0 Core]
Resolution: Agreed to the above text to resolve 6425.
<asir> where would you put it?
Bob: This resolves 6425, but there is general agreement that this approach should be used in all the specs.
DaveS: Put this text in where the first refference to a rsource is described.
<dug> Wu -don't you have a newer proposal?
<Bob> http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Feb/0020.html
<Geoff> we would prefer attributes
Dug: The element approach is better for extensibility.
Geoff: This seems overly
complicated. We would prefer simple solutions.
... What about policy?
Ashok: Policy should be easier
with element approach.
... Extension is about what we don't know now. So the most open
approach is best.
Li to do an element oriented proposal, e.g format as an element.
Li: Basically add action URI to notify element.
<Bob> ACTION: Li to prepare an element based proposal for issue 6428 [recorded in http://www.w3.org/2009/03/10-ws-ra-minutes.html#action03]
<trackbot> Created ACTION-34 - Prepare an element based proposal for issue 6428 [on Li Li - due 2009-03-17].
Gil: Should the action be a header rather than an attribute in the body?
Dug: 1) Use a single service for all wrapped messages. Then the application needs this information and the app has the body.
2) Defining new formats needs includes other information that might be needed for one service to deal with multiple styles.
Katy: Is there a way a bad action URI could cause a fault?
Ashok: Only if the service didn't recognize the action.
Dug: Note that to unwrap a wrapped message, use the actionURI as the was:action in an unwrapped message.
Gil: I would like to do a counter proposal.
<Bob> ACTION: Gilbert to write a counter proposal to 6429. [recorded in http://www.w3.org/2009/03/10-ws-ra-minutes.html#action05]
<trackbot> Created ACTION-35 - Write a counter proposal to 6429. [on Gilbert Pilz - due 2009-03-17].
Break.
Discussion of what next.
<Bob> proposal at http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Feb/0061.html
Li: Clarify that Gil will develop a counter proposal only to the action URI part of the proposal, not the rest.
Gil: Agreed.
Geoff: Issues specific to Policy , Policy Attachment, and Schema. Do these make sense?
Gil: It is unclear what policy attachement means. WSDL and Schema are clear. and polocy is not so bad.
Dug: Grouping is arbitrary. Everything returned is service specific. The proposed definition meats the intent of the spec.
Ashok: If a dialect is not specified, can you return just anything? Im therefore uncomfortable.
Geoff: This is the "Whatever" issue.
<dug> s/Whatever/Whateva/ :-)
Geoff: The MEX group is what the default would be. But also other stuff could also be sent.
Dug: This is what I proposed.
Geoff: No dialect = everything, MEX = those specified in the MEX specification.
<dug> Dug proposal: no dialect = mex, mex = everything client can see
Gil: No dialect = everything
leaves open doors to other formats.
... why woould I ask for stuff I didn't understand?
Geoff: I know what I expect from some other context.
Ashok: Counter proposal - MEX = policy, schems, WSDL, ALL = everything you know. Prohibit nothiing.
geoff: Would like a default.
Dug: First resolve what the dialects mean.
<asir> Thanks Dug
Discussion about postponing this discussion pending other issues. All agreed.
Dug: Make it like the other 5 specs.
Resolution: Agreed to resolve 6639 as proposed by Dug.
Dug: Three choice, one dialiect, no dialect, MEX dialect, but no way to say what the client wants.
katy: What if the client can't return everything requested.
Dug: This is covered in the spec - empty section
Gil: What about duplicates?
Dug: Up to the service.
Asir: This is an optimization of multiple requests.
Geoff: If this enough, or do we provide a complete dialect selection language?
Asir: What about the migration path?
Ashok: There will be other changes. I don't believe this is required by the charter.
<gpilz> The Web Services Resource Access Working Group will take as its starting point the Member Submission versions of WS-Transfer, WS-ResourceTransfer, WS-Enumeration, WS-Eventing and WS-MetadataExchange. In order to avoid disrupting the interoperability of existing implementations, WS-MetadataExchange, WS-Transfer, WS-Eventing and WS-Enumeration should remain compatible with protocols and formats that depend on them, and offer a smooth migration path from the submis
<gpilz> "offer a smooth migration path"
<Yves> smoothness is in the eye of the beholder
Resolution: Agreed to the proposal to resolve 6604 as in comment #1
There was some general discussion around how we address our charter requirement to "offer a smooth migration path". This is a separable issue, but Bob plans to track which issues may need migration actions later.
Bob: Will someone write a proposal.?
<scribe> ACTION: Geoff to write a draft proposal for management of migration notes. [recorded in http://www.w3.org/2009/03/10-ws-ra-minutes.html#action06]
<trackbot> Created ACTION-36 - Write a draft proposal for management of migration notes. [on Geoff Bullen - due 2009-03-17].
Geoff: For consistencey with the resolution 6398.
<dug> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6500
Katy: Proposed just renaming the Metadata element and moving the any.
<gpilz> <mex:Metadata>
<dug> <mex:GetMetadataResponse>
<dug> <mex:MetadataSection...> ... </mex:MetadataSection> *
<dug> xs:any *
<dug> </mex:GetMetadataResponse>
<dug> <mex:GetMetadataResponse ...>
<dug> <mex:MetadataSection...> ... </mex:MetadataSection> *
<dug> xs:any *
<dug> </mex:GetMetadataResponse>
Asir: Is there really any change needed.
Gil: But what about xs:any.
<scribe> Postponed to tomorrow to allow consideration overnight..
Ashok: Policy covers the whole space any way.
Asir: The dialect define the type of the returned element. In policy attachment case, it says it is here.
Ashok: The spec says policy can
be attached to various places.
... We need an example.
Asir: It returns a policy attachment association to external policy.
Postpone while people talk to home base.
Gil: There are many policy types and where they can be attached, it need to be clearer what is meant by the dialect.
Asir: All the dialect says in the
format of the message, not about what it means.
... The semantics is included in the metedata elements
returned.
Dug: Clarification: they may only mean something if they are understood including relationships.
Asir: yes.
Gil: Whay just ask for policy?
Dug: Look for updates.
Gil: Maybe we just need to spell out just how little information is implied by MEX. e.g. just format and version.
Dave: If we just specific type etc, why are any of these included in MEX.
Dug: Either we include each URI and define them or do nothing.
Asir: The list is extensible.
Dug: What is in a WSDL respons only the binding is included?
Dave: Could we just describe a namespace URI?
Gil: It should really point to a schema element.
Complicated multi part example discussed.
Bob: This is probably not the
right issue for this discussion.
... Propose close without action 6675.
Bob: Propose to close 6676 with no action.
Rresolution: close 6676 and 6675 with no action
<Bob> ACTION: Gilbert to raise issue for explanatory text wrt 6675. [recorded in http://www.w3.org/2009/03/10-ws-ra-minutes.html#action08]
<trackbot> Created ACTION-37 - Raise issue for explanatory text wrt 6675. [on Gilbert Pilz - due 2009-03-17].
Bob: Near closing, so lets discuss schedule for tomorrow.
All: agreed.
<li> bob, we'd like to postpone 6430
Bob: Please would all group members please look over the IRC chat now and raise issues now.
Li: Postone 6430 until after 6401 and some others relates.
Recessed until 9:00 March 11.