See also: IRC log
<TonyR> scribe: tonyr
plh: wanting help with action item - cannot see HTTP headers in the logs
arthur: showing the location of
the HTTP headers, concerning good messages
... we're using the WSI test tools
... we're not catching the messages as XML, because the message
may not be XML, or it may be well-formed XML
plh: should steal the code from
the Addressing test tools that transforms the WS-I format into
more useful format
... should be relatively easy because we're only interested in
relatively few headers
lengthy discussion of logging details - need to switch logging on and off to isolate each test case, and whether it would be simpler to split the log ourselves.
plh: have enough information to proceed now
jonathan: in addressing we crafted tests in the form of X-Paths, here we have complex X-Paths
plh: but in addressing we didn't have a description - here we do
arthur: we can use the Component Model Interchange format to provide the X-Paths
plh: aim is to have the tools ready by the time of the ftf - just have to write the tests
jonathan: there's a lot of work there: every test will require a custom X-Path
arthur: what about using
schematron?
... we need a format for the log file - can probably base it on
the addressing work
jonathan: need to tackle the
question of running all the test cases into a single log file -
much easier for testers, but harder to parse, because we need
to be able separate the test cases
... need to ensure that the test case id is embedded in the
message
arthur: we have the WSDL files for all of our tests - we can use them
jonathan: that's different from the addressing tests - only had one endpoint
arthur: we could play back a log file either as a client or as a server
jonathan: looking at an example - perhaps we can include some basic scripting for the tests in the WSDL file in some form other than comments
arthur: perhaps in the documentation, or in the test metadata?
jonathan: in the metadata would be good. Or perhaps we could simply say "run through the operations in the order in the WSDL file"?
arthur: volunteers to take on Jonathan's actions, allowing Jonathan to focus on how the ftf will run
plh: will get the log transformations done in 2 weeks
jonathan: does someone volunteer to write a change to the test metadata to incorporate scripting?
omnes: chirping crickets...
discussion of using the existing test metadata, particularly the "expected result" information
arthur: perhaps we can include assertions in the test metadata, perhaps even multiple assertions, to check the expected results
<scribe> ACTION: Arthur to document how to add test cases, and how to run the scripts for the test cases [recorded in http://www.w3.org/2006/10/12-ws-desc-minutes.html#action01]
<scribe> ACTION: ALL to ponder how to run the tests [recorded in http://www.w3.org/2006/10/12-ws-desc-minutes.html#action02]
<pauld> scribe: pauld
Review of Action items [.1].
[Interop]
? 2006-07-06: [interop] Jonathan - create validation-report
stylesheet.
? 2006-07-20: [interop] Jonathan to add timestamps to result
stylesheet.
? 2006-09-21: [interop] Philippe to transform HTTP headers in
the logs to XML format.
WG
CLOSED 2005-07-21: Pauld to write a proposal for a working group
report for requirements for schema evolution
following closure of LC124
? 2006-07-06: Glen to contribute some extension test cases.
? 2006-09-21: Jonathan to check periodically that SPARQL has added
schemaLocation.
DONE [.3] 2006-09-28: Youenn to propose an alternative syntax for MTOM
if F&P is removed
? 2006-09-28: Marsh to suggest some generic conformance text
? 2006-09-28: Jacek to follow up with Karl Dubost to get info
about RDF issue 297.
DONE [.5] 2006-10-05: Jacek to send response email noting his concern.
DONE [.4] 2006-10-05: Jonathan to add issue 81.
Current Editorial Action Items
? 2006-09-28: Editors to factor the "extra" MEPS out of the
specification (Part 2) and make a new NOTE
DONE 2006-10-05: Arthur to revise appendix to include this (CR80)
text.
Note: Editorial AIs associated with LC issues recorded at [.2].
[.1] http://www.w3.org/2002/ws/desc/#actions
[.2] http://www.w3.org/2002/ws/desc/5/cr-issues/actions_owner.html
[.3] http://lists.w3.org/Archives/Public/www-ws-desc/2006Oct/0011.html
[.4] http://www.w3.org/2002/ws/desc/5/cr-issues/#CR081
[.5] http://lists.w3.org/Archives/Public/www-ws-desc/2006Oct/0006
last week's minutes approved
discussion of the LC124 everlasting action
<JacekK> my second action fulfilled: http://lists.w3.org/Archives/Public/www-ws-desc/2006Oct/0006
<scribe> ACTION: pdowney to review the Schema WG note on versioning in 1.1 [recorded in http://www.w3.org/2006/10/12-ws-desc-minutes.html#action03]
Marsh: up and coming interop
event logisitics and registration on our public page
... please note my Email address and affiliation has
changed
http://www.w3.org/2006/10/interop2-logistic.html
http://www.w3.org/2002/09/wbs/1/wsdl_interop2/
plh: will update registration to canvas opinion for a social event
arthur: looks like one for the Addressing WG
gil: they already got it
youenn: sent a proposal, took the
existing F&P for engaging MTOM and repurposed them for XML
extensibility
... reused the MTOM URI to namespace the extension element
http://lists.w3.org/Archives/Public/www-ws-desc/2006Oct/0011.html
Marsh: what does "optional" mean, didn't see an answer in the thread
youenn: a client may use HTTP
headers such as content negotiation, server decides
... same semantics as with the existing features and
properties
Marsh: any interaction between wsdl:required?
youenn: yes, wsdl:required gives the required property optional value
Marsh: a client can ignore it, send text/xml, but server may return XOP which I can't digest
youenn: content negotiation may allow a client to preclude returning XOP
Marsh: multi-part encoded envelopes?
youenn: with content-negotiation, you can specify XOP, XML, or Multi-part related
Marsh: and then some people may want SwA ..
ack, Arthur
arthur: should be a WSDL
namespace, rather than the XMP one
... we're going to define a schema, we don't have the right to
own that namespace
plh: we could ask
permission
... send them mail
roberto: I'm perplexed by the optionality, even a client which doesn't know about the extension has to be aware of the negotiation. We're giving license to a server to suprise clients
Marsh: we need to add a statement to say, if you get text/xml then you have to explicity have marked XOP as an allowable returned media type
youenn: required MTOM is very useful for output message
plh: why are we talking about content negotiation here
youenn: content-negotiation only applies to the output message
plh: thought optional marker means it isn't *required*
roberto: not the semantics of wsdl:required we've been using
youenn: two things: whether the
client can send MTOM, and if the client has a choice to send
and receive MTOM (that is support and engage)
... we can make a refinement, need to think about it
Marsh: it's a tricky area, we may
need a parameter rather than reusing wsdl:required
... we're discussing this under removing F&P, does this
hold back our discussing removing F&P?
... not personally interested in adding this proposal, what are
the implications of adding another element
jjm: it's not adding, but moving existing functionality
arthur: were the semantics with F&P clear of engaging MTOM, you'd still need another spec
youenn: that spec already exists
arthur: not for engaging in WSDL 2.0
discussion of existing F&P engagement and wsdl:required
arthur: don't overload wsdl:required, add another attribute
Marsh: existing F&P engagement was clear?
Tony: it's becoming clear it wasn't clear
plh: WS-Policy may want to review this assertion
arthur: what's wrong with Canon using WS-Policy
jjm: WS-Policy isn't here now
Marsh: they may beat us, yet :-(
arthur: it's an adjunct?
plh: that may make WS-Policy happier
jacek: part line might be to use WS-Policy in which case our defining an XML extension might not be welcomed by the Policy WG
plh: asked the Policy WG, and they said it's fine
Marsh: it's more of an
implementation thing, Microsoft, for example, are more
interested in supporting usingAddressing inside WS-Policy and
not as a direct extensions
... separate spec because it needs more work, may attract
WS-Policy flak?
... (as WSO2 rep) I don't see this as being interoperable
... natural place for engaging MTOM in WSDL would be XMLP (if
they were active) possibly Policy
plh: Policy are only chartered to build a framework, XMLP are in maintainance mode
jjm: and they're not interested in description
jacek: is that the XMLP not interested, or people in the WG not interested?
plh: they're not chartered to do
more work beyond the PER
... it's going to happen here or not at all
pauld: is there interest in having a Web Services Core WG to pick up this kind of work?
plh: such a WG would be more for maintainance and not new work
discussion of how specs may be passed from WG to WG
<Jonathan> chad: new poll
<chad> new poll
chad, option 0: close with no action
chad, option 1: remove F&P with no replacement for MTOM
chad, option 2: add Canon proposal as an adjunct
chad, option 3: add Canon proposal as a separate Last Call document
Marsh: the last call protects our main deliverable being stalled by comments from the WS-Policy WG
chad, option 4: define WS-Policy assertion
tom: opposed to being forced to support WS-Policy just to use MTOM
plh: this would be similar to usingAddressing, it can be used with policy
discussion clarifiing the options
Marsh: who decides if we have to go back to last call?
plh: the Director
tom: we had a clearly marked feature "At Risk"
plh: expect WS-Policy to want to review if we add an MTOM extension
<TonyR> chad, list options
jjm: there is precident with WS-Addressing, no?
plh: separate specification may be the easiest way
tom: makes a big difference, I might implement WSDL 2.0 and not be aware of the other specification
<JacekK> chad, option 4: add Canon proposal + define WS-Policy assertion in a separate LC document
chad, option4 define WS-Policy assertion in addition to Option 3
chad, option4: define WS-Policy assertion in addition to Option 3
<TomJ> vote 2
vote: tomj: 2
<gpilz> vote: 2
<JacekK> vote: 4,3,1
<Allen> vote: 3, 2
<TonyR> vote: 4, 3, 1, 2, 0
<Jonathan> vote: 1, 4, 3
<alewis> vote: 3, 4, 2 0
<youenn> vote: 2,4
<JacekK> vote: 4,3,1,2
<TomJ> vote: 2,3,4
<Arthur> vote: 4, 3, 2, 1, 0
<plh> vote: 4,2,1
<Roberto> vote: 4, 3, 2, 1
vote: 4, 1
<jjm> vote: 2, 4
<gpilz> vote: 2, 3, 4
<Vivek> vote: 4,3,2,1
chad, count
<chad> Question: unknown
<chad> Option 0: close with no action (0)
<chad> Option 1: remove F&P with no replacement for MTOM (1)
<chad> Option 2: add Canon proposal as an adjunct (4)
<chad> Option 3: add Canon proposal as a separate Last Call document (2)
<chad> Option 4: define WS-Policy assertion in addition to Option 3 (7)
<chad> 14 voters: alewis (3,4,2,0),Allen (3,2),Arthur (4,3,2,1,0),gpilz (2,3,4),JacekK (4,3,1,2),jjm (2,4),Jonathan (1,4,3),pauld (4,1),plh (4,2,1),Roberto (4,3,2,1),TomJ (2,3,4),TonyR (4,3,1,2,0),Vivek (4,3,2,1),youenn (2,4)
<chad> Round 1: Count of first place rankings.
<chad> Round 2: First elimination round.
<chad> Eliminating candidadates without any votes.
<chad> Eliminating candidate 0.
<chad> Round 3: Eliminating candidate 1.
<chad> Candidate 4 is elected.
<chad> Winner is option 4 - define WS-Policy assertion in addition to Option 3
<jjm> (capturing my earlier comment:) for the record, my company wants WSDL soon, MTOM support and cannot rely on WS-Policy yet
<alewis> chad, detail?
chad, details?
chad, details
arthur: we can make an informative reference to WS-Policy
jjm: can we wait a week while we consider our position?
arthur: we're all agreed to remove F&P?
Marsh: we could remove F&P, if we have consensus to take option 2,3 or 4
jjm: let's do it next week
arthur: we decided to make a
decision this week
... what's the fall out from removing it, don't we need to take
action to inform people
Tony: we could ask the editors to remove F&P ahead of the decision
arthur: don't want to
branch
... we're slipping week by week
jjm: it's a big decision and it takes time
arthur: how likely is it we are going to keep F&P?
Marsh: are there any objections to removing F&P this week on the understanding we'll use Youenn's proposal in some form
jjm: I'd object to making that decision today
arthur: I'm OK to wait ONE more week, but unhappy to delay any further than that
Marsh: we can formalize the process if we wait one more week
pauld: +1 to Arthur
<TomJ> I also support Arthur's desire to not put this off any longer
<JacekK> "A Binding component that defines bindings for an Interface component
<JacekK> MUST define binding for all the faults of that Interface component that
<JacekK> are referenced from any of the operations in that Interface component."
http://www.w3.org/2002/ws/desc/5/cr-issues/#CR081
<TomJ> +1 to Jaceks text
Marsh: any objections to accepting Jacek's proposal?
RESOLUTION: close CR081 with Jacek's proposal
<gpilz> This resolution generates a new assertion, no?
jacek: we'd like the WG to review our Last Call specification for Semantic Annotations for WSDL
<JacekK> ack
<Zakim> JacekK, you wanted to add a short call for review for SAWSDL to the end of the agenda
<scribe> ACTION: Jonathan to conduct a review of the SAWSDL Last Call WD [recorded in http://www.w3.org/2006/10/12-ws-desc-minutes.html#action04]
Marsh: expect to skip telcons as our issues list dries up