See also: IRC log
<trackbot> Date: 15 December 2009
<MartinC> 3531498 is me
<Bob> scribenick: Katy
dug: Pls can we talk anbout 8201 if pos
<scribe> Chair: Agenda agreed
No objects, minutes approved
RESOLUTION: Approve publication of 17 Nov snapshots as heartbeat
<Bob> http://www.w3.org/2002/ws/ra/tracker/actions/open
Bob: No meetings after this one until Jan 5th
<dug> I don't recall Gil getting Bob's permission to go to Australia
<dug> clearly, he was out of order
Bob: Presume 8176 will stay until next meeting.
Gil: 8284 Text in WSDL 1.1 not consistent with schema.
Bob: One of problems was BP restricted to HTTP and SOAP 1.1
Gil: Need carefully crafted text.
Asir: we have a bunch of ws-ra spec wsdls already and we can already build BP compliant.
Gil: We are talking about references to WSDL 1.1 in our specs when WSDL 1.1 is broken
Asir: but why does this matter as our WSDLs are ok
<asir> ... also our operation descriptions are okay
<gpilz> here's what I'm talking about: 4.7.12 Describing headerfault Elements There is inconsistency between WSDL specification text and the WSDL schema regarding soapbind:headerfaults. R2719 A wsdl:binding in a DESCRIPTION MAY contain no soapbind:headerfault elements if there are no known header faults. The WSDL 1.1 schema makes the specification of soapbind:headerfault element mandatory on wsdl:input and wsdl:output
Asir: Our WSDLs are BP compliant so why does it matter
Gil: We should reference a version of WSDL 1.1 that is BP compliant - where the inconsistencies have been addressed
<asir> WS-RA specs don't define any headers
<dug> so a BP compliant WSDL isn't WSDL 1.1 compliant?
Bob: How about we keep the normative ref to WSDL (same as BP) but mention that we would expect implementations to be conformant to the requirements of BP?
Asir: but wouldn't we need to list the requirements
Bob: It would be up to the
implementer to choose
... depending on what they were doing
Asir: We would like to consider this
<scribe> ACTION: Gil to produce some specifics for 8284 that reflect the relevant aspects for ws-ra [recorded in http://www.w3.org/2009/12/15-ws-ra-minutes.html#action01]
<trackbot> Sorry, couldn't find user - Gil
<Bob> ACTION: Gilbert to produce some specifics for 8284 that reflect the relevant aspects for ws-ra [recorded in http://www.w3.org/2009/12/15-ws-ra-minutes.html#action02]
Katy: Described 2nd proposal
Asir: We like the proposal but have some further changes marked up
<trackbot> Could not create new action (failed to parse response from server) - please contact sysreq with the details of what happened.
<trackbot> Could not create new action (unparseable data in server response: local variable 'd' referenced before assignment) - please contact sysreq with the details of what happened.
Asir: we can walk through now
<dug> I'd like more time to review Asir's proposed edits
<dug> http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Dec/0067.html
<li> anybody having problem with http://lists.w3.org?
<dug> yes I'm having 'issues' too
<Yves> no problems should be with www.w3.org currently
Asir: Would like to call out assumption for 8.1
<dug> email site is ok- main w3 site is slow/down
<dug> e.g. bugzilla is down for me
Asir: and describe other details of the markup
Dug: Please could we have a marked up copy
Ashok: I made some comments on
the syntax - in particular the layers of wrapping needed in the
Metadata
... could be a new issue
... but this is related to how the policy is attached to the
endpoint so I am wondering what to do with these concerns
... Issues are: 1) schema url is duplicated
... 2) We have 3 layers of wrapping
(08) Identifier='http://www.w3.org/2009/09/ws-mex'>
(09) <wsdl:definitions name='StockQuoteMetadataExchangeMetadata'
(10) targetNamespace='http://www.w3.org/2009/09/ws-mex'
(11) xmlns:wsdl='http://schemas.xmlsoap.org/wsdl/'
Asir: The above is just that the
identifier is a hint for what is in the WSDL - the identifier
is optional
... so is not required
(04) <wsa:Metadata>
(05) <mex:Metadata xmlns:mex='http://www.w3.org/2009/09/ws-mex'>
(06) <mex:MetadataSection
Ashok: Why not take out mex:Metadata?
Asir: Because the mex:metadata
may be embeded in transfer response, epr or mex
... transfer requires one wrapper which is first wrapper in
resource representation
... the consistent wrapper is useful for consistency
Dug: The mex arwpper in transfer
is only useful in transfer when all metadata is wrapped in one
blob
... if you are moving mex metadata documents it provide
consistency
... but other metadata - wsdl, schema - does not have wrapper
so ws-t, http do not get consistency through mex metadata
... I think common usecase would be 'give me your wsdl' where
the mex:metadata is not require
Ashok: Agree
... We have not reached agreement on the points that I
raised
... Issue is: The syntax of attaching mex matadata should be
simplified
Bob: Would anyone object to opening an issue?
Katy: I would like to discuss Ashok's issue now so that we can get it in the open
Bob: As this is a substantive issue, my recommendation would be to open it now
<Yves> if it's just syntax, that's not a major change
Asir: This is not a huge issue - no new feature
<dug> its a bit more than syntax
<dug> he really wants to be on the queue :-)
dug: The usecase is when the metadata is something as simple as wsdl - it is not clear whether this is just a wsld document directly under wsa:metadata or whether it is wrapped in a mex:metadata wrapper. That needs to be cleared up.
Gil: I don't think it's advisable to leave this until last call. We should focus on it now
Asir: Embedding WSDL directly into ws-addressing metadata - was taken out as there was no implementation experience
Ashok: Not relevant here
<dug> I have no idea what WSA 2.2 is
<dug> lol
<asir> Here it is http://www.w3.org/TR/2007/WD-ws-addr-metadata-20070627/#metadatinepr
Bob: I am disappointed that this issue did not get out at the time of issue morotorium
Ashok: Issue 7728 may include this and would be a good location for discussing this issue
<Yves> same as Bob, don't want new issues to postpone LC indefinitely
<scribe> ACTION: Asir to write up proposal with changes incoporated [recorded in http://www.w3.org/2009/12/15-ws-ra-minutes.html#action03]
<trackbot> Created ACTION-130 - Write up proposal with changes incoporated [on Asir Vedamuthu - due 2009-12-22].
<Ram> Resolve with new proposal http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Dec/0045.html
<Ram> Resolve with new proposal http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Dec/0045.html
Dug: This is about the mex:all
dialect uri
... but Gil also notices (8297) has a def of mex dialect from
getmedata operation that is wrong
Bob: Any objections to resolving with message 45?
none
RESOLUTION: 8200 resolved with action described in message 45
<dug> 8297: http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Dec/0058.html
RESOLUTION: Issue 8297 resolved with proposal in message 58
<Ram> Proposal: http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Dec/0048.html
<dug> "When this repeating OPTIONAL element is present, the response MUST include only Metadata Sections corresponding to metadata specified by the combination of the URI, Identifier and Content attributes of each of the Dialect elements. For each Dialect element if there is no metadata for that combination of attributes then the response MUST NOT include any Metadata Sections for that Dialect element."
RESOLUTION: Issue 8202 resolved with message 48
<dug> http://www.w3.org/Bugs/Public/show_bug.cgi?id=8205
Asir: From mailing list - intent is a single element and so we should change schema/text to indicate that it is unique
dug: as there's an xs:any element, we can't prevent multiple mex:md anyhow so there's no point in making it unique
Gil: having individual metadata:section elements in each mex:metadata is no different from multiple metadatasections in one mex:metadata
<gpilz> mex:Metadata(A, B) == mex:Metadata(A) + mex:Metadata(B)
Asir: What we are actually discussing is optimal syntactic form. We should have use case for multiple
Dug: I am happy to write up Gil's issue
<Yves> why can't multiple MEX entries be alternatives and not complement each other?
<Yves> if you have no control, you have no control on the meaning
<asir> agree with Yves
Asir: this doesn't fix it. I would like to understand a motivation. WS-T fixes the extensibility so why can't we
Dug: ws-t isn't the same problem
Gil: There are advantages in
having multiple mex:metadata sections in an EPR if multiple
components are working on different sections
... I don't understand the motivation of imposing a restriction
instead of just having one
Dug: mex:medatadata has extensibility points. Having multiple mex:metadata elements allows folk to have different extensibility elements for each - not restricted to one
Asir: Gil's point is a
programming API - a serialisation issue so it's not
relevant
... I would like to see a proposal written up with reasons for
this function
Yves: If there are multiple mex:metadata elements, then there would be no way of indicating the relationship between the various mex:metadatasections
<asir> Bob: we have to leave for another meeting
bob: this discussion will go to the email list as out of time
<asir> Happy holidays to everyone!!!
<asoldano> +1
<Yves> bye all!
<Yves> trackbot, end telcon
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/8279/8297/ Found ScribeNick: Katy Inferring Scribes: Katy Default Present: Doug_Davis, +0759029aaaa, Bob_Freund, [Microsoft], +039331574aabb, li, +984999aacc, +3531498aadd, +1.408.970.aaee, +039331574aaff, asoldano, MartinC, Tom_Rutt, Ashok_Malhotra, +0207202aagg, Yves, +1.408.642.aahh, +984999aaii Present: Doug_Davis +0759029aaaa Bob_Freund [Microsoft] +039331574aabb li +984999aacc +3531498aadd +1.408.970.aaee +039331574aaff asoldano MartinC Tom_Rutt Ashok_Malhotra +0207202aagg Yves +1.408.642.aahh +984999aaii Agenda: http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Dec/0060.html Found Date: 15 Dec 2009 Guessing minutes URL: http://www.w3.org/2009/12/15-ws-ra-minutes.html People with action items: asir gil gilbert[End of scribe.perl diagnostic output]