See also: IRC log
Paul introduces the new Vote bot, and we vote on what name it should be given.
<p> <em>Timestamps are in UTC.</em></p>
<pauld> vote, say hi
<pauld> vote, question: what shall we name our baby?
<Marsh> vote, option 0: vote (status quo)
<Marsh> vote, option 1: Chad
<Marsh> vote, option 2: Kerry
<jeffm> vote option 2: 666
<dmoberg> vote, option 1:Chad
<Marsh> vote, option 3 straw
<Marsh> vote, option 3: straw
<Roberto> vote option 4: Spartacus
<jeffm> voite option 5: 666
<Marsh> vote, option 4: Spartacus
<Marsh> vote, option 5: 666
<Marsh> vote, summarize
<GlenD> vote: 1, 4, 0
<Marsh> vote, options?
<pauld_> vote: 1, 3
<RebeccaB> vote: 0,3
<Marsh> vote: 1, 3
<umit> vote, option 100: umit
<Allen> vote: 1, 3
<alewis> vote: abstain
<Roberto> vote: 4, 3, 5, 0
<TonyR> vote: 3, 1, 4
<charlton> vote, options?
<asir> vote 1, 2
<jeffm> vote: 5, 1, 3
<hugo> vote: 3
<youenn> vote: 4,0
<bijanp> vote, options?
<asir> vote asir 1,2
<swinkler> vote: 1
<pauld_> vote, votes?
<Marsh> vote, option 7: VoteBot
<JacekK> vote: 3, 7, 0
<bijanp> vote: option 4, 5
<GlenD> vote, count
<umit> vote: 4, 100
<vote> Winner is option 1 - Chad
<Marsh> vote: Gudge: 100
<Marsh> vote, count
<vote> Winner is option 1 - Chad
<pauld_> vote, detail
* vote Election: what shall we name our baby? * vote Method: British Columbia STV * vote Number of Ballots: 14 * vote Threshold Name: Droop Static Whole * vote Threshold Value: 8.0 * vote Delayed Transfer of Surplus: Not Enabled. * vote Batch Elimination: None * vote 8 candidates running for 1 seats. * vote R| 0| 1| 100| 2| 3| 4| 5| 7|Exha|Surp * vote --+----+----+----+----+----+----+----+----+----+---- * vote 1| 1.0| 5.0| 1.0| 0.0| 3.0| 3.0| 1.0| 0.0| 0.0| 0.0 * vote 3| 1.0| 5.0| | | 3.0| 3.0| 1.0| | 1.0| 0.0 * vote 4| | 5.0| | | 4.0| 3.0| 1.0| | 1.0| 0.0 * vote 5| | 6.0| | | 4.0| 3.0| | | 1.0| 0.0 * vote 6| | 6.0| | | 5.0| | | | 3.0| 0.0 * vote 7| | 7.0| | | | | | | 7.0| 0.0 * vote Round 1: Count of first place rankings. * vote Round 2: First elimination round. * vote Eliminating candidadates without any votes. * vote Eliminating candidate 2. * vote Eliminating candidate 7. * vote Round 3: Tie when choosing candidate to eliminate. * vote Tie at round 2 between 0, 100, 5. * vote Tie at round 1 between 0, 100, 5. * vote Tie broken randomly. * vote Eliminating candidate 100. * vote Round 4: Tie when choosing candidate to eliminate. * vote Tie at round 3 between 0, 5. * vote Tie at round 2 between 0, 5. * vote Tie at round 1 between 0, 5. * vote Tie broken randomly. * vote Eliminating candidate 0. * vote Round 5: Eliminating candidate 5. * vote Round 6: Eliminating candidate 4. * vote Round 7: Eliminating candidate 3. * vote Election over. Candidate 1 is elected. * vote Winner is 1.
<GlenD> Scribe: GlenD
<scribe> Agenda: http://lists.w3.org/Archives/Public/www-ws-desc/2005Feb/0071.html
Discussion and demo of Paul's new votebot
<pauld_> vote, i'm going to rename you chad :-)
Assign scribes
3/3 AM : Glen
3/3 PM : Bijan
3/4 AM : Roberto
3/4 PM : Allen
Swapping morning and afternoon in agenda for Friday - start at 8AM
Jonathan summarizes - move alternate schema language bindings to appendix, Bijan volunteered to coordinate
Jonathan: What else remains of issue 70?
Bijan: Data Access group now has a dependency on WSDL 2.0
... Hard to use schema to validate RDFXML, so nice to use RelaxNG for that...
... So in a single WSDL you might want both
Asir: There was a proposal from DBooth about mixing languages
<asir> David Booth's proposal - " include a note in the spec saying that if someone combines multiple schema languages may be a problem, and we have not solved this problem".
Sanjiva: What are the problems here?
Amy: Basically, it's that behaviour is undefined
Amy describes scenario where both RelaxNG and Schema are used
RelaxNG proposal reuses the element="" attribute
scribe: so there can be a QName conflict
Jonathan: Question - do we want to allow different defs in the same file?
... Question - do we want to allow referring to different defs with the same attribute?
Bijan: One operation, input has single XML schema type. output can be one of two types (schema, relax). Could do two ops, but nicer if it's one...
various: are they the same?
Jacek: If not, they are like a <choice> with the choices being in different schema langs
... Do we want to allow one QName defined by both schema/relax and have it be the same?
... Should RelaxNG contribute to the element declarations component? I'm doubtful, but if so it shouldn't contribute a different component....
Jacek: We could also say RelaxNG defs are not element declarations (different component)
... Could say that there is EXACTLY ONE component on a message ref which defines the schema (small s)
Roberto: Two probs. Sec 2.1.3 (element decls) says it's a set - we require all elements to be isomorphic to a schema element decl... could require the QName for each element decl to be unique in the set (preventing alternates)
... 2nd prob - message reference (2.5.3) says "the" element declaration, already implicitly says that there will be exactly one.
<sanjiva> +1 for Roberto's approach for saying the set of GEDs in {element declarations} consists of unique QNames
<JacekK> we already say what Roberto wants to say in 2.1.2 penultimate para
Sanjiva: We decided not to have "type" on the output, so if you want choices, you use the choices facility of the schema language
... If we disallow other schema langs to contribute to the element decls, we disallow the use of our binding
... since the binding refers to that component
<umit> +1 to Roberto's approach
Tony: Multiple schemas seem to be about using multiples to allow people who understand various langs to understand a given WSDL (you can use one and ignore one, say)
... That leads to picking exactly one, not alternates
Glen: I saw it rather like Tony - alternates (which describe the same infoset) seem like a good possibility
Jonathan: Can we focus on that question (should we allow alternates)?
Roberto: Worried about interop / sychronization problems
Amy, etc : Not our problem
Jonathan: DavidB suggested that alternate descriptions should be representations of the same thing - if they're different, your problem
Sanjiva: When processor is building stuff, it looks at the QName and picks whichever descriptino of that QName it likes
Asir: Let's dedicate element="" attribute to just schema, and use something like rng:element="" for RelaxNG, etc
Sanjiva: That doesn't solve the problem...
Jacek: 2.1.1 already solves Roberto's problem
... already can't have two components with same QName
... Let's allow multiples, which are strongly suggested (but not enforced) to describe the same thing
<Zakim> JacekK, you wanted to point roberto is trying to add that constraint in the wrong place
Jacek: Multiple schema versions would generate a single element decl component
Sanjiva: So you pick one for schemas, but not for other langs?
Jacek: Logically it's a merge (for versions of schema), but ok to think of it as pick one...
Sanjiva: element decls component designed for extensibility of XML Schema versions
... In order to deal with RelaxNG, etc. - it should be OK for the processor to choose how it builds that component
... Our component says the four things we need (localname, namespace name, etc) - you can populate that any way you like
<JacekK> editorially, we are inconsistent in saying "element declaration" and "element declaration component"
Sanjiva: But you should only do it once (pick one of multiple descriptions that should all be the same infoset)
Asir: So this is implementation dependent?
<asir> "This specification allows mixing schema languages within WSDL and such usage is implementation-dependent".
<umit> +1 to Sanjiva
Glen: Don't like the wording here (too loose, implies "mixing" languages together?).. idea is good
Tony: Do not want to enforce sameness requirement - we can't.
<Zakim> JacekK, you wanted to ask about how it fits with OWL classes
Jonathan: i.e. does an OWL class define local name, namespace name, etc....
Jacek: OWL doesn't define that
Sanjiva: Then it doesn't apply
Jacek: Messages are XML elements... the story about OWL could be that OWL has to create glue from an OWL class to an element declaration.
... If there is a really funky type system, then they can use new components (not element decl)
<pauld> sorry, i care deeply about OWL ..
Sanjiva raises issues about complexity of alternate componentry, Glen notes that we don't necessarily need to go there (OWL binding to WSDL can create element decls)
Bijan: Asir's text - does mixing schema languages imply implementation dependent or extension dependent?
Jonathan: Implementation chooses... using standard WSDL requiredness criteria
Bijan: Not so hard to prove equivalence between some schema langs
Sanjiva: Could define any kind of extension (java, indigo, etc) which tells how a "thingy" turns into a GED
... That would work for OWL classes as well
<pauld> <a href="http://www.flickr.com/photos/psd/5812127/">http://www.flickr.com/photos/psd/5812127/</a>
Roberto: MustUnderstand on a relaxng extension would seem like you need to validate both?
... i.e. if a schema (implicit MU) and RelaxNG (required=true) are both present, then the infoset must validate both
Jonathan: 1) Element decls are unique per QName, up to impl to pick one if multiple
... 2) They're not unique, and everything that's required MUST go into that list, other stuff MAY
<Zakim> GlenD, you wanted to ask about validation and the element declaration component
Tony: OK for different schema langs to have different constraints, as long as they're subsets - should be OK
<TonyR> Perhaps: as long as they have the same XML representation...
<sanjiva> Given the complexity this conversation is heading towards, I would prefer to get married to XML Schema and only XML Schema and live with it. Sigh.
(discussion of wsdl:required and the semantics thereof)
COFFEE COFFEE COFFEE
break for coffee
resume
straw polling options
<pauld> chad, hi!
<pauld> chad, you're owner hasn't written that page yet :-(
<pauld> chad, proxy all TonyR's votes to me!
Jonathan describes the usage of two versions of schema to allow for versioning and backwards-compatibility
Amy: 2nd use case is about wsdl:required being used to indicate that you have to understand relax to deal with message ref components which are only defined in terms of relax
straw poll (this time for sure)
<pauld> chad, hi
chad, you're not pauld
fine chad, stick with your illusions of grandeur
<pauld> chad, i'm pauld
<sanjiva> chad, who are you? cousin of votebot?
<pauld> chad, die die die
So we're going to clean this up to be consistent, but the poll is about whether or not a given QName has exactly one description, or potentially multiple ones
unique: 6
non-unique: 5
abstain : rest
can't live with unique : 0
can't live with multiple : 2
consensus is to make it unique
<scribe> ACTION: editors to clarify in sec 2.1.3 and elsewhere that there be only a single element declaration in the set for each QName
Jonathan: do we need to clarify if/how a processor chooses which one?
<Roberto> need to make corresponding edits to sections 2.3.3 and 2.5.3 too
Sanjiva: let's just say it's not defined behavior
<Roberto> how is that interoperable? "no defined behavior"??
<charlton> "include a note in the spec saying that if someone combines multiple schema languages it may be a problem, and we have not solved this problem"
<charlton> (David Booth's proposal)
<scribe> ACTION: editors to add text along the lines suggested by David - "include a note in the spec saying that if someone combines multiple schema languages may be a problem, and we have not solved this problem"
Discussion of type system extensibility and CR - should we make sure someone wants to use it in order to get out of CR?
<scribe> ACTION: Jonathan to formalize the CR criteria bag and drop "testing type system extensibility" into it
Jonathan: Do we want people to really review this thing? Do we just publish it or do we do a Last Call or somesuch?
Bijan: need to think about it
<scribe> ACTION: Jonathan will ask the WG what is the publication plan for the type system note around 3/17
[Issue left open temporarily, to see if Issue LC5f resolution applies.]
<Marsh> <a href="http://lists.w3.org/Archives/Public/www-ws-desc/2005Jan/0099.html">http://lists.w3.org/Archives/Public/www-ws-desc/2005Jan/0099.html</a>
upcoming straw poll re: how to deal with schema / import / extensibility
<pauld> chad, option 1: schema is like any other extension
<pauld> chad, option 2: implicit wsdl:required on schema
<pauld> chad, option 3: barf
<pauld> chad, question: are we going to eat lunch on time?
<pauld> vote: alewis: 2, 1
<pauld> chad: alewis: 2, 1
<anish> chad: 1
<umit> chad: 2
<pauld> chad, say hi
<Roberto> vote: 2, 1
<dmoberg> chad: 2, 1
<JacekK> chad: 2
<Roberto> chad: 2, 1
<Allen> chad: 2
<pauld> chad, options?
<RebeccaB> chad: 1,2
<alewis> chad, option 3: provide elements in wsdl namespace corresponding to xs:schema/import
<alewis> chad, options?
<youenn> chad: 1
<bijan> chad: abstain
<hugo> vote: 1, 2
<sanjiva> chad: 2
<jeffm> chad: 2,1
<hugo> chad: 1, 2
<asir> chad asir 1,2
<Marsh> chad: 1, 2
<jjm> chad: 1
<pauld> chad: 1,2
<JacekK> chad: 2, 1
<sanjiva> chad: 3
<pauld> chad, voters?
<TonyR> chad: 2,1, 3
<pauld> chad, voters?
<dbooth> chad: dbooth abstains
chad: 1
<pauld> chad, count
<chad> Winner is option 2 - implicit wsdl:required on schema
<pauld> chad, count
<asir> chad, detail
<chad> Winner is option 2 - implicit wsdl:required on schema
<sanjiva> chad: 2
<asir> chad: 1
(discussion about defining the options)
Sanjiva: Option 1 seems to beg for profiling...
Jonathan: But why force support of Schema 1.0 forever??
<TonyR> chad: 1, 2
Sanjiva: Same can be said re: XML 1.0 for SOAP
<JacekK> chad: 1, 2
<alewis> chad: 1, 2
<alewis> chad: count?
<TonyR> chad, count
<chad> Winner is option 1 - schema is like any other extension
<alewis> chad: detail?
<pauld> chad, detail
<anish> option 4 (d): make it a requirement that whenever xs:schema is used, wsdl:required='true' MUST be specified
<umit> option 4 is still not making understanding schema required
<asir> chad asir 1
<pauld> chad: 1
<Roberto> chad: 2
chad, what is the question?
chad, options?
* chad question: are we going to eat lunch on time? * chad option 1: schema is like any other extension * chad option 2: implicit wsdl:required on schema * chad option 3: provide elements in wsdl namespace corresponding to xs:schema/import
<pauld> chad, votes?
<dbooth> chad, option 4: Require wsdl:required=true be written on every xs:schema and xs:import element
<RebeccaB> chad: 1
<dbooth> chad: 1
<jeffm> chad: 1
<dbooth> chad: 1, 2
<sanjiva> chad: 3, 2
<anish> chad: 4, 1, 2
<hugo> chad: hugo abstains
<umit> chad: 2,4
<alewis> chad, count?
<chad> Winner is option 1 - schema is like any other extension
<asir> chad: 1`
<asir> chad: 1
<dbooth> chad, details?
* chad Election: are we going to eat lunch on time? * chad Method: British Columbia STV * chad Number of Ballots: 18 * chad Threshold Name: Droop Static Whole * chad Threshold Value: 10.0 * GlenD ding ding ding - lunchtime * chad Delayed Transfer of Surplus: Not Enabled. * chad Batch Elimination: None * chad 4 candidates running for 1 seats. * chad R| 1| 2| 3| 4|Exha|Surp * chad --+----+----+----+----+----+---- * chad 1|12.0| 4.0| 1.0| 1.0| 0.0| 2.0 * chad Round 1: Count of first place rankings. * chad Candidate 1 is elected. * chad Winner is 1.
break for lunch - we will come back and take a formal vote on whether schema should be required (regardless of text)
sorry, vote is option 1 or option 2
<Marsh> chad, hi
<bijan> Meeting: WS-Description Face-to-face
<bijan> Chair: Jonathan Marsh
<bijan> Scribe: bijan
<scribe> Agenda: <a href="http://lists.w3.org/Archives/Public/www-ws-desc/2005Feb/0071.html">http://lists.w3.org/Archives/Public/www-ws-desc/2005Feb/0071.html</a>
Lots of scary talk about good standing
<pauld> s/.. flying to this meeting ...//
Vote on proposal resolving 5F
Options A and B
<pauld> chad, please leave us
Marsh: Glen has an amendment which I shall propose: Interop is important so you should support XML Schema (without a version number, so that as schema moves forward, so does the recommendation)
Roberto: Does this mean we remove the normative status of XML schema?
Glen: No
hugo, if there objectors, how does this amendment affect you? Does it make you change? If it won't change you, I have another idea that might help
glen: that's umit and sanjiva. So how do you feel about that? "If you use WSDL, we strongly recommend usign W3C XML Schema for interop"
Umit: I'm not conviced yet. Let's hear Hugo.
Hugo: Define WSDL2.0 without a required Schema, plus a profile (in a separate document) which sez: USE SCHEMA WITH WSDL 2.0
<dbooth> (Paraphrasing Hugo:) separate out the specification of the WSDL 2.0 language from specifying a conformance profile
Marsh: That could be a conformance clause in our current document
anish: even if you say that you should|must use schema in WSDL, it's still the case that a wsdl processor could ignore it
hugo, So conformance is defined against both WSDL and the 2005 profile
hugo: so we can't ignore the profile
anish: so define clearly what conformance to the profile means
Roberto: so the profile reintroduces the wsdl processor
hugo: perhaps, not sure
umit: yes
sanjiva: who is you
glen: any processor
Marsh: Conformance to WSDL and XML Schema
anish: that's not enough
pauld: who believes that we need to take care of this? the market will sort it out
anish: there's a confusion between requiring schema in *every* wsdl, and *if* the wsdl has schema stuff, you should obey that
bijan: doesn't this just add another level of indirect?
Marsh: it might make the document conformance cleaner
dbooth: yes, I believe that
Marsh: two issues [but scribe lost them]
sanjiva: there seems to be consensus that a wsdl processor should support schema. The question is 1.0, 1.1 etc.
Marsh (as MS rep): there are situations when you don't want schema (e.g., cell phones). Danger of profile
sanjiva: Yes, but we want to encourage schema for interop
dbooth: that's what you are doing
sanjiva: we are mandating in the language
dbooth: this gives allows us other profiles
TonyR: and you can rev profiles independantly of reving the language
Marsh: Statement or profile?
Sanjiva: no seperate document
Glen: introduces another (unnecessary) identifier
Marsh: "strongly recommended"
umit: why do we have a wonderful test suite? What are we testing? How are we doing conformance?
TonyR: you can test conformance to the profile
[lots of chatter]
[about test cases]
Roberto: I don't undertand the reference to cell phones. If we take out processor conformance, we only have document conformances. If someone creates a cell phone profile that sez: "No schema". That's a subset of all wsdls. They'll never see a schema, so how does this change anything?
GlenD: But this is an interop encouragement. if you want maximal interopt between different domains [Marsh's words] Use schema
Roberto: [some sort of disagreement]
GlenD: It's better to build up than to chop out
Roberto, anish, umit: there is no chopping
GlenD: wsdl:required enforced a processing model. If you put one inthere, *someone* needs to understand it.
dbooth: not exactly. If you put in a binding, do you have to understand it? No, because some processors might not care about bindings
Marsh: Stop. Option A won, but there were objections
... Let's consider a statement along the lines of glen's. Does it help?
sanjiva: I remove my objection
umit: I withdraw too with the caveat that we add glenesqitude.
Marsh: We have consensus to select option A augmented with a statement that is glenesque
sanjiva: a clarification point of glen about required? and understanding
[some chatter betweeen glen, sanjiva, dbooth, and umit about the non-normative note that may mention processing]
GlenD: Point 7, friendly amendment, [which he'll type in]
<GlenD> Thus, the meaning of the element cannot be determined without understanding the attached extension.
Marsh: any objections
dbooth: saying cannot is not correct
GlenD: cannot is definitely correct
dbooth: cannot means that it's not possible to understand
marsh: can everyone live with glen's formulation as entered above?
group: YES
GlenD: question about section 8.1 in core. need clarification of sentence fragment from dbooth's action
<asir> I see xml 1.1 in section 8.1 :-(
GlenD: What 8.1 needs to say: [he'll type it cause he talks really too fast for this scribe]
[lots of chatter about wordsmithing 8.1]
Marsh: glen is this editorial?
GlenD: yes it is
... Some stuff about why it's obvious
marsh starts expressing qualms
GlenD reassures marsh
[chatter]
Marsh: can I declare this editorial?
Group: PLEASE
Marsh: any other objections or question about 5f
... Can I close it?
GlenD: I have some concerns about implementation
RESOLUTION: Issue LC5f will be closed with option A plus amendment plus editorial
<dbooth> Resolution to LC5f (accepting option A): <a href="http://lists.w3.org/Archives/Public/www-ws-desc/2005Jan/0099.html">http://lists.w3.org/Archives/Public/www-ws-desc/2005Jan/0099.html</a>
RESOLUTION: Issues LC75r, LC75v, LC70 will be closed as a consequence of lc5f
Open: that LC63 and LC52b will also be resolved by the resolution of LC5f
Considering LC63
RESOLVED Close LC63 with the resolution of LC5F
Discussion of 52b
jacek raises the OWL Class issue again
JacekK: can we postpone while I think
Marsh: Postponed.
<scribe> ACTION: JacekK to figure out what he thinks on this
RESOVLED: LC52b is closed by discussion with raiser and some clarification
<sanjiva> ACTION: part1 editors to check the consistency of statements related to {message content model} in the message ref component definition and the mapping table.
[some chatter about the Z notation, and how to generate it for public]
<JacekK> resolution to LC52b: {message content model} is optional, missing when a different type system is in use
sanjiva: what is the noramtive document, with or without Z?
Marsh: with, even if hidden
[talk about the makefile and arthur using Ant]
Marsh: This issues is in a confused state, so the best we can hope for is action items etc.
sanjiva: can we not push it back and just take a formal vote and move on?
Marsh: Do we have a coherent set of options
GlenD: No.
sanjiva: yes we do, the status quo or the incoherent option
GlenD: but daveo has investment etc.
sanjiva: but how much must we accomodate those who aren't here?
asir: I have to do xml schema stuff tomorrow so I don't want it moved then
marsh: let's get it clear now
asir: Proposal, let's look at all the issues, consider, pick one, then tweak it, then vote on it
... second path: come up with a decision tree
Marsh: which do you prefer?
asir: easier to pick one proposal and tinker
... 5 options (including status quo)
Marsh: we'll discuss each of these options
<pauld> chad, how you doing?
bijan: can we make this easier?
sanjiva: amendment: let's break it in headers in abstract and then in the soap (separately)
asir: there are several dimensions. I can present that and then show how proposal relate to that
... Dimension 1: First class mechanism to describe headers
Scribe will now just transcribe what Marsh is writing on the pad
Mechanism to describe headers
element/type
How to hook header into WSDL
1st class: interface
2nd class: binding
3rd class: Features and properties or extension
Support at SOAP binding/HTTP binding
Syntax
<alewis> chad, help?
Proposal|Mechanism|Class|Support
DO | type | 1+3 | S/H
A | element | 1 | S/H
B | type | 1 | S/H?
C | type | 2 | S/H?
SQ | type | 1-3 | S/H
S=Support for SOAP binding
H=Support for HTTP binding
H?=No current HTTP support but easy extension
DO=DaveO's proposal
SQ=Status quo
The proposal differentiate over the issues described at the below uri
<Marsh> <a href="http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC76d">http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC76d</a>
[discussion between glen and asir that scribe at least cannot follow]
<pauld> chad, poll?
<pauld> chad, question?
Does the Status Quo deal with all the issues of lc76d
<pauld> chad, die die die
Thus far, GlenD and asir have been vindicating status quo
6th subpoint turns out to have been based on a misunderstanding
[acclaim by glen, asir, umit, sanjiva, and others]
sanjiva: IBM's position is that we don't want abstract headers to creep back in
... proposal: go from status quo to proposal C
asir: our position is we'd like to move to something simple *and* independent of F&P
GlenD: why independent of F&P?
asir: we think that headers are first class so we shouldn't use an extension framework
sanjiva: so, ok with C?
asir: yes, I can live with C
GlenD: DaveO wants it at the abstract level
Marsh: some intersection between several proposal and not between others
... let's examine C to see if it can win
<dorchard> Definitely at the abstract level.
<dorchard> I'm in the TAG/XML Schema joint meeting on extensibility/versioning.
<dorchard> Any chance of deferring this for a bit of time?
hugo, I'm unhappy with a Soap only solution
asir, the details are worked out for SOAP but it could be worked out for other protocols
hugo, let me get some clarification. Will we remove the application data (AD) feature?
hugo, are we replacing an abstract feature with soemthing soap specific
sanjiva: I don't actually endorse proposal C, but something similar to proposal C with devils in the details
backchat between sanjiva and asir about reconciling their Cs (replacing type with element)
GlenD: Task force can present in the half hour before the break
dorchard, we can defer until after the break. will you be able to make it?
<dorchard> yes.
<dorchard> if the break ends not before 3:30 :-)
Break is scheduled for 15:20
over at 15:20
<Marsh> <a href="http://lists.w3.org/Archives/Public/www-ws-desc/2005Mar/0000.html">http://lists.w3.org/Archives/Public/www-ws-desc/2005Mar/0000.html</a>
GlenD: Task force formed in Austraila
... Trying to solve longtime issues. Lots of use cases
... Lots of questions about how to decribe important stuff in wsdl
... and the relations between SOAP, WSDL, and WS-Addressing
... Consider the soap layer: impoverished set of MEPs. So how to map from WSDL one way to SOAP?
... options: beef up soap meps with a true oneway. simulate one way with soap twoway.
... what do we want to have happen, and who does it? SOap group? WSDL Group? A merry band of wanderers?
... Big question: If you have a SOAP binding (like ours), can you *extend it* without changing the URI?
... MTOM not an example of doing this, since SOAP allows extensibilty for media type. SOAP does not say this about MEPs
... So, what to do with a new soap MEP?
... Since you *really* have to understand the MEP, it might be ok
... MarkH, can we satisfy these use cases with what he have now? How painful is it?
... Some HTTP magic with redirects
... A kind of asynch, but is it a good idea?
... Do we need to rev soap's level? or can we do it by errata, e.g., add a sentence about mep extensibility
... up to the wsdl level. Do we want to be able to say I've got a WSDL mep and I want to bind it to a different (maybe more than one) SOAP MEP
... or do we want a tighter coupling between the WSDL level and the SOAP/Binding level
... But we don't want to discuss this now.
sanjiva: is this against our last call?
GlenD: yes..well...do we have any issue?
Marsh: yes, 101, 102...
GlenD: Do we need to make any serious changes to WSDL to support these use cases?
sanjiva: we enable everything! by extensibilty!
GlenD: yes, but we want to encourage interop for known topics like addressing etc.
umit: the async task force vote wasn't against *enabling* it, but against *doing* it
GlenD: questions about how hard it'd be even with extensibility
... Moving along. Transport as well as mep variability
... WSLD support for range of options for transport (e.g., for replies) and similar
sanjiva: are we being asked to deal with these for WSDL 1.1
GlenD: The WSDL working group is not being asked to do this for 1.1
sanjiva: Charter says, "don't touch 1.1"
hugo, maybe should we consider it
Marsh: it's part of the web services activity, so we could have our charter revised or interpreted to deal with that
sanjiva, but it's clearly out of our charter!
Marsh: but there's a larger discussion here.
GlenD: It might happen in WS-Addressing
hugo, sorry, I thought you were asking the larger question about dealing with the Addressing questions for WSDL 2.0, not the specific should we help them deal with 1.1
hugo, concentrate on 2.0, and the charter supports that
GlenD: can we drop this, since I don't think we'll do it
... this report is not about making recommendations, but raising the issues in a clear way
... Now that the WSDL group is informed, the wsdl group can punt as they see fit
Marsh: can we relate these to issues 101 and 102 since they relate
... "Subject: Summary of decision tree for Addr/Desc groups
The following is a series of questions which should be considered a tool
for the WS-Description and WS-Addressing groups to use in considering
the plans/actions necessary in order to support various "asynchronous"
use cases as discussed by the async task force. The use-cases we've
been discussing can be found on the archives of the task force list [1].
These questions are divided into SOAP-related, WSDL-related, and
Addressing-related "buckets".
* The SOAP layer
Q. It seems a new SOAP MEP (one-way) is very likely needed. Alternately
it *might* be possible to simply alter the request-response MEP in order
to support the possibility of a "null" response envelope. Does this
work need to happen?
Q. Who should do this work?
a. XMLP group
b. WSDL group
c. Addr group
Q. Regardless of its technical feasibility, it's pretty clear that no
one yet implements a "polling" style callback using HTTP as described by
Marc in [2]. Do we want to try to encourage this pattern? If so:
Q. Where should the work be done to describe it?
a. Errata to SOAP spec
b. Separate note
Q. how do we indicate in the WSDL that this is available/used?
Q. Does this change the SOAP MEP, or is it still a SOAP req/resp?
Q. Assuming both of the above affect the SOAP 1.2 spec(s), can the
changes be published as "errata" so as not to cause a full release cycle
of the spec(s)?
* The WSDL layer
The essential question at the WSDL layer is "what, if anything, do we
need to change in WSDL (both 2.0 and 1.1) to enable the important
use-cases that fall under the general heading of 'async'". This breaks
down into two categories - actual changes to WSDL core, and extensions.
Clearly WSDL core changes (for 2.0 at least) need to happen under the
auspices of the WSDL group. Extensions could be built either by the
WSDL group or the Addressing group (and "who does the work" is therefore
an implicit secondary question to each of the ones in this section).
So here are some questions (these do not necessarily presuppose
solutions):
Q. Do we want to enable/support the case where a single WSDL
operation/MEP (request/response, say) can bind to multiple SOAP MEPs?
(i.e. the seemingly-common use case where the request comes in on one
HTTP interaction with a <replyTo>, and the response goes out in another
transport interaction (either HTTP or otherwise))
Q. Do we want to enable/support the above with multiple transports?
(req is HTTP, resp is SMTP)" == Issue 101
Marsh: Q. Do we want to enable/support the above with multiple transports? (req is HTTP, resp is SMTP)" == Issue 101
sanjijva: issue 102 is the in-only thing
umit: 102 is the SOAP doesn't give us what we need
(scribe didn't mean to paste all that stuff from glen's message, above)
alewis: we could resolve this simply with a construct/extention that can appear in binding or binding operations or endpoints which says "I support dynamic addressing, and here is the list of uris taht I understand"
... "Send me something back that contains one of these addresses"
... Similarly for the out-only [scribe got a bit lost]
... it doesn't have to be more complicate it enough
sanjiva: make it simpler, just put in a tag (or have Addressing do it)
alewis: be nice to have a list of bindings.
Marsh: If you are interested, join the Task force which meets on Weds
GlenD: TF has determined that it should continue meeting and act as a coordination group for WSDL, XMLP, and WS-A
alewis (correction): for out-initial meps, the wsdl contains a list of protocol bindings (like for in-initial), and the service promises to supply endpoints for each in the outgoing message
jeffm: a lot of discussion revolves around what you expect to see for an in-out
... what should the wsdl do?
BREAK!!!!
Dancing by the harbor
Break is Over
<pauld> chad, i know i've been poking around with your insides, but please do your best :-)
<TonyR> chad, what is blue?
Marsh: asir and sanjiva have had some break time discussion about the proposal C space
... and it seems promising
hugo: (of asir) Why would you want to set up a mechanism to send headers just for a particular binding. That would mean that is is just one particular binding of your abstract applicaiotn that require headers
GlenD: What's this headers thing?
hugo: I thought that was the proposal, to add headers support to the binding
<Roberto> chad, please help
GlenD: The AD feature lets you express abstract things like "Please do security" which, in soap, will poke some headers
... so the abstract claim is, "I want this functionality" i.e, "I have some side band information to communicate too"
Hugo: still uncomfortable with that
asir: hugo, you want the abstract thing?
hugo, I like the AD feature
pauld: Lots of BTers are using headers, usually for good reasoning.
... headers for vendors or middleware! I warn people against mucking with them but they still do it.
... so providing a good header mechanism is a strong requirement for so many people
... we are trying to force people into good practices rather than enabling them to describe what they do and want to do
[some discussion; background filling in for dorchard]
GlenD: there are certainly cases where people are really doing the header thing. But there are lots of other times which look like the first case, but really doing and wanting to do something else
pauld: Ok, that's how you see the world. But it's not clear people want to not do it the headers way
<GlenD> Glen: There are people who are describing headers today in terms of "send this element". There are also cases where they are doing that when they mean "do this functionality".
<GlenD> ...the latter being more in the realm of modules/policy/f&p
Marsh: where we started was can we add simpler syntax for the AD feature
umit: observation that will irritate sanjiva -- In all the proposals, we make diffrent buckets of headers etc. but there is no additional help at the description level/interface level. If the header go wrong and I want to describe what happens I have to muck at the abstract level! So a "binding only" thingy can require abstract mucking
[chat between glen and umit involving holes, AD feature, etc.]
sanjiva: A policy/reliable messaging case
umit: I'm not talking about this. AD feature does not go far enough
hugo: pauld, what do you prefer of the proposals?
... and what the rest of the group thinks. I would like an informative poll
<pauld> i worry about vendor adoption of the AD feature
<alewis> chad, new vote
<chad> new poll
<alewis> chad, question: which of the choices do people prefer?
SQ == Status quo
A == <a href="http://lists.w3.org/Archives/Public/www-ws-desc/2005Feb/att-0019/first-c">http://lists.w3.org/Archives/Public/www-ws-desc/2005Feb/att-0019/first-c</a>
lass-headers-A.html
<alewis> chad, option A: first-class headers using elements, binding to SOAP and HTTP
<charlton> essentially inline messages, right?
A==<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2005Feb/att-0019/first-class-headers-A.html">http://lists.w3.org/Archives/Public/www-ws-desc/2005Feb/att-0019/first-class-headers-A.html</a>
<sanjiva> yes basically inlined messages
B==<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2005Feb/att-0019/first-class-headers-B.html">http://lists.w3.org/Archives/Public/www-ws-desc/2005Feb/att-0019/first-class-headers-B.html</a>
<alewis> chad, option B: first-class headers using types, binding to SOAP and HTTP
<alewis> chad, option C: headers defined at the binding level, using types, initially only for SOAP (but HTTP possible)
C==<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2005Jan/att-0094/soap-header-blocks.html">http://lists.w3.org/Archives/Public/www-ws-desc/2005Jan/att-0094/soap-header-blocks.html</a>
<hugo> chad, list options
D == <a href="http://lists.w3.org/Archives/Public/www-ws-desc/2005Jan/0040.html">http://lists.w3.org/Archives/Public/www-ws-desc/2005Jan/0040.html</a>
<alewis> chad, option D: AD feature with syntactic sugar for direct usage.
<alewis> chad, option S: status quo, the existing AD Feature
asir: AD feature is optional!
<alewis> chad, options?
<alewis> chad, list options?
pauld: which ones do asir and dorchard prefer
<alewis> chad, remove option s
asir: I want a slim option that will get acceptance
pauld: waht if you were the only one voting?
asir: C + extended to HTTP
<alewis> chad, list options?
dorchard: don't like C, prefer either B or D (DO)
<youenn> <a href="http://lists.w3.org/Archives/Public/www-ws-desc/2005Feb/0046.html">http://lists.w3.org/Archives/Public/www-ws-desc/2005Feb/0046.html</a>
RebeccaB: Is this entirely related to SOAP and HTTP or also apply to other transports
pauld: it can apply to other transports
RebeccaB: which proposals apply to the wider range of transport
pauld: could do it in your binding
RebeccaB: so you prefer one of the binding levels?
[discussing of C vs. B (I think)]
umit: Why move from SO? Jeff Schlimmer wants something [scribe misses]. And if we don't satify him, he'll come back.
Marsh: I've not talked with jeff about it, but i may not be
pauld: i haven't talked with him, but i can imagine his comment was able backwards compatibility for expressing this stuff, at least being *able* to express the same stuff in both
asir: in my editing of the soap binding, for the migration of headers users in 1.1, C will help, but A and B will work, but optional features don't help
<JacekK> chad: S, D, A, B
<umit> it seems to me that issue 76 d issues seems to request SOAP 1.1 compatible solution. I wonder whether A, B, or D will help closing the issue. Just an observation reading the actual issue statement
<asir> chad: C, B, A
<sanjiva> chad: C, S
<Roberto> chad, list options
<alewis> chad: S
<Roberto> chad: C, S
<umit> chad: C, S
[youenn explains his solution: <a href="http://lists.w3.org/Archives/Public/www-ws-desc/2005Feb/0046.html">http://lists.w3.org/Archives/Public/www-ws-desc/2005Feb/0046.html</a> ]
anish: Why did we get rid of message structure?
youenn: I don't know. We so agreed. Two ways, inline it (complicated) or create element=qname since it worked 90% case
asir: This covers stuff beyond 76b?
youenn: why?
asir: because it changes soap binding?
youenn: it's a module
GlenD: right, it doesn't change anything unless you use the module.
Marsh: Seems a little obscure. You wouldn't notice it if you were looking headers.
pauld: how would you map 1.1 headers to this?
<anish> it seems to me that we would have been better off by keeping the message structure and allowing minOccurs, maxOccurs and xsi:nil in WSDL
GlenD: you just take the parts and pop them into an element and then route
<RebeccaB> chad: C,S
<hugo> chad, list options
<pauld> chad, list voters
<dorchard> chad: B, D
<hugo> vote: B, D, S, A, C
<TonyR> chad: abstain
[discussion about how you serialize into HTTP]
<hugo> chad: B, D, S, A, C
<Allen> chad, B, D, S
<alewis> chad, option Y: youenn's proposal
<pauld> chad: B, D
<Allen> chad: B, D, S
<dmoberg> chad c, s
<alewis> chad, list options
<dorchard> chad: B,D,A
<pauld> chad: dmoberg: C, S
<alewis> chad, list voters
dorchard: I'm against C because things like BPEL work at the interface level and won't be able to access things at the binding level
<Marsh> option Y: youenn's proposal to have a single wrapper element at the abstract level, containing headers and body, bind it using a module into SOAP body/headers. Without the module, the whole wrapper element get's bound.
<Marsh> chad, option Y: youenn's proposal to have a single wrapper element at the abstract level, containing headers and body, bind it using a module into SOAP body/headers. Without the module, the whole wrapper element get's bound.
<GlenD> chad: S, D
<alewis> chad, list options
* chad question: which of the choices do people prefer? * chad option A: first-class headers using elements, binding to SOAP and HTTP * chad option B: first-class headers using types, binding to SOAP and HTTP * chad option C: headers defined at the binding level, using types, initially only for SOAP (but HTTP possible) * chad option D: AD feature with syntactic sugar for direct usage.asir: do they want to do stuff with headers? * chad option S: status quo, the existing AD Feature * chad option Y: youenn's proposal to have a single wrapper element at the abstract level, containing headers and body, bind it using a module into SOAP body/headers. Without the module, the whole wrapper element get's bound.
asir: do they want to do stuff with headers?
<JacekK> chad: S, D, A, B, C
dorchard: yes, probably.
[some chat between dorchard, sanjiva, asir about BPEL]
<Marsh> chad: B, C
<youenn> chad: Y, S, D
<anish> chad: S, D, C, A, B
<jjm> chad: Y, C, A, B
<jeffm> chad: S,D,C,A,B
<anish> chad, list voters
chad: B, S, B, C,
<alewis> chad, list voters
chad: B, S, B, Y, C
<GlenD> chad: s, s, s, s
chad: B, S, A, Y, C
<GlenD> chad: s, d
<alewis> chad, count?
<chad> Winner is option C - headers defined at the binding level, using types, initially only for SOAP (but HTTP possible)
<alewis> chad, details?
* chad Election: which of the choices do people prefer? * chad Method: British Columbia STV * chad Number of Ballots: 19 * chad Threshold Name: Droop Static Whole * chad Threshold Value: 10.0 * chad Delayed Transfer of Surplus: Not Enabled. * chad Batch Elimination: None * chad 6 candidates running for 1 seats. * chad R| A| B| C| D| S| Y|Exha|Surp * chad --+----+----+----+----+----+----+----+---- * RebeccaB wonders how you ask Chad how a particular person voted? * chad 1| 0.0| 6.0| 6.0| 0.0| 5.0| 2.0| 0.0| 0.0 * chad 3| | 6.0| 7.0| | 6.0| | 0.0| 0.0 * chad 4| | 7.0| 9.0| | | | 3.0| 0.0 * chad 5| | |13.0| | | | 6.0| 3.0 * chad Round 1: Count of first place rankings. * chad Round 2: First elimination round. * chad Eliminating candidadates without any votes. * chad Eliminating candidate A. * chad Eliminating candidate D. * chad Round 3: Eliminating candidate Y. * chad Round 4: Tie when choosing candidate to eliminate. * chad Tie at round 3 between B, S. * chad Candidate S has the fewest votes at round 2. * chad Eliminating candidate S. * chad Round 5: Eliminating candidate B. * chad Candidate C is elected. * chad Winner is C.
Marsh: Let's push on C. Who thinks that C is a loser?
dorchard: C is a loser because at the abstract level applications will want to know whether information is in the headers or body
<pauld> chad, list votes
sanjiva: fundementally opposed to adding headers at the headers level except from SO
[chat about STV]
<hugo> chad: B, D, S, A
[disucssio of the vote]
Marsh: formal votes on in the abstract or in the binding
... between B and C?
sanjiva: what about the SQ?
Marsh: Yes, ideally we'd vote to change the SQ first.
[marsh discusses Robert's rule of order]
Marsh: we'll vote for B and C, then vote whether to change the status quo to the winner
<Marsh> chad, options?
<Marsh> chad: what options?
<alewis> chad, remove option s
Vote B vs. C
Iona: C
W3C: B
Roguewave: B
Sun: C
<Roberto> s/Roadway/RogueWave/
UMD: Abstain
Sonic: C
BT: B
Canon: C
Oracle: C
<JacekK> LFUI: C
Tibco: Abstain
SAP: Abstain
<anish> Cyclone: C
IBM: C
WebMethods: C
CA: Abstain
BEA: B
Microsoft: B
UMD: B
6 for B, 9 for C. C wins
Marsh: next vote: Fix and adopt C, or Status quo?
Iona: Yes
W3C: No
Rogewave: No
Sun: Yes
Sonic: Abstain
BT: Abstain
Canon: Non
<JacekK> LFUI: No
Oracle: Abstain
Tibco: No
SAP: Yes
Cyclone: Yes
Bea: Yes
CA: Abstain
IBM: Yes
Webmethods: Yes
UMD: Abstain
7 yes; 5 no: Adopt C carries
Marsh: Any lie in the roaders
?
Group: no
Marsh: What must we fix in option C?
Discussing: <a href="http://lists.w3.org/Archives/Public/www-ws-desc/2005Jan/att-0094/soap-header-blocks.html">http://lists.w3.org/Archives/Public/www-ws-desc/2005Jan/att-0094/soap-header-blocks.html</a>
sanjiva: my problem is that instead of using type, we use element?
(That's a scribe "?")
<Marsh> <wsoap:header element="..."/>*
marsh: is this anything more than syntax?
asir/sanjiva: yes
sanjiva: this is more consistent for the user
Marsh: acceptable to everyone?
asir: what about mustUnderstand?
<Roberto> <wsoap:header element="xs:QName" mustUnderstand="xs:boolean"? required="xs:boolean"?>*
<Marsh> <wsoap:header element="..." mustUnderstand="xs:Boolean" wsdl:required="xs:boolean"/>*
asir: goes into the binding fault and the binding reference components + new component [...]
Roberto: This goes into part 3 and we remove the AD feature from Part 1
asir: And it must be extended to the http binding
<Marsh> <whttp:header element="..." wsdl:required="xs:boolean"/>*
[some more tweaking]
asir: The whttp:header elements is avaiable to use within the SOAP HTTP binding
Marsh: We will prevent people from using HTTP headers that are already used by the protocol
... Does the working group accept these tweaks?
Group: yes
RESOLUTION: 76d is closed with the above decision
<scribe> ACTION: to asir to double check the subissues of 76d to see if they should be raised as issues and to do so
no
RESOLUTION: Issues 24, 53, 61f (dup of 76d) closed by the resolution of 76d
Start again at 8am tomorrow
End at 4 pm
<jjm> bye
Switched morning and afternoon schedules
H. Thompson is here from 8 to 9 about the media type note
anish: lots of editorial changes. Please check to make sure you like 'em
Meeting adjourned