See also: IRC log
<scribe> ScribeNick: bijan
Minutes approved for week prior to F2F
Minutes approved for the F2F
--------------------------------------------------------------------
3. Review of Action items [.1].
DONE 2005-06-16: Amy to provide test cases for MEPs not described
in Part 2, due 2005-07.
? 2005-07-21: pauld to write a proposal for a working group
report for requirements for schema evolution
following closure of LC124
? 2005-09-22: Marsh will look at section 5.6 in relation to IRI,
due 2005-09-26.
DONE [.4] 2005-09-22: Glen will reword sentence in 5.9.1,
due 2005-09-26.
? 2005-09-26: Arthur to figure out how to treat built-in schema
types. (LC315), due 2005-10-06.
? 2005-09-26: DaveO to draft a response and send to the WG.
(LC335), due 2005-10-06.
? 2005-09-26: Arthur to draft above as a proposal to be able to
close this issue (LC344#5), due 2005-10-06.
? 2005-09-26: Hugo to look at sections 4.2 & 4.3 of part2 and
see whether the first sentences (paragraphs) are
no-ops. (LC344#5), due 2005-10-06.
? 2005-09-26: Roberto to change the order of the union in the
schema in 4.1.2 to match the order in the prose.
(LC344#5), due 2005-10-06.
? 2005-09-26: Arthur to look for simplification options for
comment 12 of 344. (LC344#12), due 2005-10-06.
? 2005-09-26: Jonathan to point this out when it gets implemented
(LC344#13), due 2005-10-06.
? 2005-09-26: Sanjiva and Roberto to investigate defaulting with
interfaceless bindings (LC333), due 2005-10,06
DONE [.3] 2005-09-26: Hugo will write up the resolutions for review
(LC345), due 2005-10-06.
Current Editorial Action Items
? 2005-07-21: Arthur to add stable identifiers for each
assertion, due 2005-09-26.
? 2005-09-26: editors to fix the first paragraph of section 4
... does not make sense at all right now.
(LC344#5), due 2005-10-06.
? 2005-09-26: Editors to add a sentence saying {address} is
optional because it could be defined by other
means, such as an WS-A endpoint reference or maybe
the scenario does not require an address.
(LC344#13), due 2005-10-06.
? 2005-09-26: Editors fix "Case Elements NOT cited" in 6.8.1.2
header to be "Case of elements NOT cited" (LC345),
due 2005-10-06.
DONE 2005-09-26: Arthur to reword references in 5.3 to avoid
confusing WS-addressing endpoint references
(LC346), due 2005-10-06.
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/lc-issues/actions_owner.html
[.3] http://lists.w3.org/Archives/Public/www-ws-desc/2005Sep/0063.html
[.4] http://lists.w3.org/Archives/Public/www-ws-desc/2005Sep/0052.html
alewis's test case DONE
<scribe> Scribe: Bijan Parsia
Arthur's done nothing this week (which is a good thing, for Arthur)
action " 2005-09-26: editors to look at sections 4.2 & 4.3 of part2..." assigned specifically to Hugo
F2F registration closed
Reopening for a day
<Marsh> ACTION: Marsh to reopen registration. [recorded in http://www.w3.org/2005/10/06-ws-desc-minutes.html#action01]
Marsh: nothing done yet
JacekK: How do I get into CVS? Makes publication easier
Arthur: I could committ it for you
JacekK: That's great for publication, but I need access as well.
Marsh: Issue on "description" component seems resolved. Should I track issues on the issues list?
JacekK: That's great. No current issues.
Marsh: I'll put Description on
the WG issues list
... In order to get the mechanisms flowing
<Marsh> ACTION: Put the Description issue on the issues list [recorded in http://www.w3.org/2005/10/06-ws-desc-minutes.html#action02]
Marsh: Need any admmin help?
Arthur: Sure, put up issues on
the issue list
... .7 -- all errors are corrected. .6 refers to a fictitious
server (scraped from primer)...let's add an xml-categlog
... A validator is working and picking out errors for us!
Yay!
<Marsh> ACTION: Marsh to track .6 on issues list [recorded in http://www.w3.org/2005/10/06-ws-desc-minutes.html#action03]
Marsh: Arthur's issue about indicating test assertions?
Arthur: would be nice to have a subtle indicator in the text that something is a testable assertion with a link to the table of test assertions.
Marsh: Perhaps a superscript
Arthur: Just a constant symbol
Marsh: Anyone have a concern with this approache? No? great. Go for it arthur.
Arthur: About the ids...I thought that they should meaningful, i.e., derivied from the text. Marsh suggested numbers. Preferences?
Marsh: used numbers on other specs; and moved from meaningful names for issues to numbers
Hugo: Numbers have ordering issues.
Marsh: WS-I uses requirements numbers (4 digits) and they never reuse numbers
JacekK: we could divide by 100s and have some grouping
Marsh: Not widely used, so perhaps not a big deal
Marsh: WSA considered it and said "sure go ahead", make soap action granular down to the message layer. Tom disagrees?
Tomj: But that's just WSA foisting it's errors upon us! It's an operation level thing
GlenD: But it is message level! And messages can't be reused between operations
TomJ: Ok, that's technical true, but the elements get reused.
Question about the WSDL point of view
Discussion with Tomj including asir, glen, arthur, and jacekK (and others of the SOAP Cabal!)
Marsh: Is the issue that if I come out with a new MEP with 2 inputs and 2 outputs that TomJ thinks they should all have the same soapaction?
TomJ: well, wasn't talking about output, but ok. Want to maintain the old way of doing things
GlenD: but take axis which does things to refute tomj's view
JacekK: Migration path for
WSDL1.1 is to put it on the Initiating message
... it will work the same and isn't much different
Arthur relates this to security issues and some history
TomJ: .NET uses soapaction all over.
GlenD: Yes
Arthur: Is it required in .NET?
TomJ: Soap1.2 soapaction is deprecated, right, GlenD?
GlenD: Not deprecated but made option?
TomJ: It was required before.
JacekK: now wsa makes soapaction requried again?
GlenD: yes, and it would be really nice to tie it to a message identifier
GlenD articulates a prefered design which he things WSA will not adopt
TomJ: Impact analysis: Change some syntax. Touches both interface and binding? soap:action will be permitted on all message elements?
GlenD: yes, and it won't be in the http header except in SOAP1.2
Some arcana about parameters on media type vs. header
TomJ: I won't stand in the way of this.
kevin: What's the use case for out message?
GlenD: I have a use case!!! I always have a use case!!!!! Some case where different messages are possible and indistinguishable from the xml level, this provides a bit of extra datat
Marsh: What about action values on faults?
TomJ: This doesn't bubble up to the interface; strictly a soap binding thing. I still think it's confusing for WSDL 1.1 users
Marsh: Current spec means that we are silent about soapaction on every message except the initial one
TomJ: That's a feature! Silence on soapaction isn't just golden, it's diamond!!!
More obscure SOAPing from the SOAP cabal
TomJ: More impact analysis: Lots of changes to the adjunct
Hugo: While it's a change for the user, I think it accurately describes SOAP. Perhaps clarifying text in the primer would help alleviate the former?
TomJ: Fair enough...but come on! Leave it alone! Why is this so late to the game?
Marsh: WSA + WSDL + soapaction, then specifying things at different levels is confusing
TomJ: But WSA does the job? Why duplicate?
Marsh: but WSA specifies how to keep it consistent.
TomJ: but that means that you
give the action twice (and keep them connected)
... If you are using addressing you won't use soapaction and if
you aren't, then you want it to work as normal
... Is there an advantage for WSA for this functionalty?
<Arthur> It is recommended that the same value be used to identify sets of message types that are logically connected in some manner, for example part of the same "service". It is strongly RECOMMENDED that the URI be globally unique and stable over time.
<Arthur> The presence and content of the action parameter MAY be used by servers such as firewalls to appropriately filter SOAP messages and it may be used by servers to facilitate dispatching of SOAP messages to internal message handlers etc. It SHOULD NOT be used as an insecure form of access authorization.
Some discussion from Asir about Soap 1.1 and 1.2
<Arthur> http://www.w3.org/TR/2003/REC-soap12-part2-20030624/#ietf-action
Arthur: The soap spec seems LESS granular than what we already provide...why is WSA pushing for finer grain
Marsh: Alt proposal (from Arthur, supported by TomJ) to pushback on WSA for why they are so granular on SOAP1.2 soapaction
JacekK: Don't think syncrhonizing with WSA is a good idea! We already have two actions which are undefined and we should keep them in synch (which is better for users)
Arthur: I'm in favor on syching with WSA. We should describe what they want to do.
<Zakim> hugo, you wanted to ask XMLP people about the sentence quoted by Arthur
Marsh: Didn't we have a lot of discussion about using wsa action to indicate operation
Hugo: I'm startled, nay, shocked, by this sentence that Arthur dug up from the SOAP 1.2 spec. Any comments from the SOAP Cabal?
ominous silence
JacekK: We didn't know what to do, so we suggested something that would be helpful.
Asir: Like a best practice?
JacekK: It is normative
ominous close spec reading
JacekK: Take it with a grain of salt.
Marsh: We support using using the same action throughout your service. So the question is why support *only* at the operation level (and thus this best practice)
Arthur: Why not just be permissive about where action appears?
GlenD: Hey! F&P! already allows this!!
TomJ: Can. Worms. Keep it sealed
Marsh: To the use cases! Using WSA action or not. If not, do we want to be more flexible in the latter case?
TomJ: Close with no action
JacekK: Do we have someone who wants to use soapaction on other messages, i.e., a user of the proposed feature?
GlenD: prolly .NET
Marsh: I can investigate
... I could investigate?
TomJ: But we're down to the wire!!!! If we can't come to consensus now on the new feature, let's close it with no action.
Marsh: I want to investigate it a bit, but TomJ has raised a number of important issues. Short amount of time next week to resolve it.
Hugo: When WSA reviewed the draft...they approved my proposal but what would they say if we deny this?
TomJ: But we don't restrict wsa:action
Marsh: But they have text about synching it.
TomJ: let them change! THey've only been at it a year!
<Marsh> ACTION: Marsh to investigate LC301 re .NET scenarios. [recorded in http://www.w3.org/2005/10/06-ws-desc-minutes.html#action04]
JacekK: If we clarify soapaction to apply only to the initial message they are free to talk about the other ones
<scribe> ACTION: Marsh to investigate the .NET use of soapaction [recorded in http://www.w3.org/2005/10/06-ws-desc-minutes.html#action05]
Marsh: fell through at the f2f...no record of closing
Hugo: The issue arose when I noticed that we were using IANA media type token and not defining it. So what should it be? Should we allow parameters, etc.
Marsh: And we made some decisions
to resolve kendall's issues
... We're cloning the same syntax from the media type note.
Allows multiples, parameters, etc.
Hugo: Which closes 338 as well
Marsh: yes, though it's unrecorded.
Hugo: So, I have no clue what I should be saying :)
Marsh: 337 is closed and I think
that closure resolves 338 as it gives us a solid definition of
the token but it interacts badly with Hugo's proposal to use
uris
... But Hugo's proposal doesn't help with wildcards, etc.
Hugo: I'm rethinking. There could
be, e.g., alternative serialization for the same media
types...if we use a regular token how does this work?
... The Token is just a name and the serialization determines
the actual type.
Marsh: Do you want more cogitation opportunity?
Hugo: Hoping for feedback from the group
ominous silence
<Marsh> ACTION: Hugo to review his LC304 proposal in light of the LC337 resolution. [recorded in http://www.w3.org/2005/10/06-ws-desc-minutes.html#action06]
Hugo: Ok, I'm behind on the minutes from the F2F, so I would like another week to come up with a revised opinion
Marsh: We resolved to allow wildcards but didn't record the closing of it. Anyone think there is more to do on this issue?
Happy silence
Marsh: 338 is about wildcards and 337 is about faults.
Hugo: Are the SPARQL people happy with this?
Bijan: yep, pretty much
Marsh: we gave them more than
they strictly need
... Objections to closing 338 with the resolution for 337? no.
good
Marsh: I forgot what this was about
<Marsh> http://lists.w3.org/Archives/Public/www-ws-desc/2005Sep/0063.html
<Marsh> RESOLUTION: LC338 closed by LC337 resolution.
Hugo: We talked last week about
issues around the HTTP binding. We disucssed 3 fixes. Allowing
HTTP post with x-www-form-urlencoded (forbidden by a bug in the
spec which forced applicaiton/xml for posts).
... Second bug: Our microsyntax forbad serializing the message
only and entirely in the message body when POSTing
... Proposal to replace obscure / notation with something
else.
... In the process of understanding this, we generated a
clarifying table. I have produce a version of spec with these
fixes
... fixed bugs 1 and 2. But fixing the / notation is an issue,
since we don't need it
... either you are using an HTTP method with no message body,
so you don't need it. Or, you are using an HTTP with message
body in which case, the {} syntax puts things in the URL and
the default puts everything in the body
DaveO: The reason for the / was
so that just one part of the instance data would get serialized
into the URL.
... without having to create a new XML type.
Hugo: Ok, there is a case (thanks
DaveO), where you have
... "more stuff" in your type than you want in your URI.
Marsh: Essentially a versioning use case?
DaveO: No!!!! Not a versioning thing at all!!!!!!!
Marsh: then why would you have this overstuffed type in the first place?
DaveO: you want to reuse the type in a number of places.
alewis: But it has to be a simple type right?
Marsh: So, daveo, I might have a structure with a lot of data and depending on the operation I might want to pick out different data
DaveO: yeah, otherwise there are cases where you get an explosion of types
Marsh: So, DaveO is against removing the feature.
<alewis> i still don't like the slash notation, at all.
Hugo: Yes, and that's fine. I'll
put it back in a new proposal.
... While fixing the bug...I basically implemented Sanjiva's
table. But we lost a feature. So the bug, posting
formurlencoded would serialize it as application/xml. DAWG
said, we can't do what we want to do. We fixed it.
... So, we do lose a feature...before we could serialize a
little bit in the uri and a little bit in the application/xml
(or all as applicaiton/xml)
... that is the {}notation only works with formurlencoded so no
longer works with application/xml
Marsh: do we want to add this back?
Hugo: I'll paste the URI of the example of what we lost
<hugo> http://www.w3.org/TR/2005/WD-wsdl20-adjuncts-20050803/#_http_operation_location_notcited_body
Alewis: can still do this with formurlencoded bodies, but not with application/xml
<hugo> http://www.w3.org/2002/ws/desc/5/09/wsdl20-adjuncts.html#_http_operation_location_notcited_body
DaveO: So before, we could put some of the data in the url when in post...but we couldn't split the data
alewis: Not exactly, we put all the data in the body, said we were sending formrulencoded but actually said appication/xml
DaveO explains how it all comes from REST
Splitting issues.
Marsh: It's hard to figure out
how to split up XML and we got a minimal solution.
... Hugo, is the removal a good thing, or a (negative) side
effect.
Hugo: it's definitely a side
effect. See the two URIs in irc
... Why not generalize the {}notation for all our
serializations?
Marsh: will you work on it more
and we can decide on it next week.
... Anyone else can work on this, given Hugo's schedule?!
DaveO: I would like to, but I can't.
<Marsh> ACTION: Charlton to augment Hugo's proposal with parameters for all serializations, and syntax for suppressing parameters. [recorded in http://www.w3.org/2005/10/06-ws-desc-minutes.html#action07]