See also: IRC log
<Marsh> Potential scribes: Jeff, Kevin, DaveO, Dale, Hugo, Amelia, Arthur, Allen
<Marsh> I've got more...
<Marsh> ... Youenn, Jacek, Roberto, Glen, Anish, Umit, Tom, JJM, Paul, Tony
<alewis> Scribe: Alewis
Web Services Description Working Group Face to Face, morning session 20 July 2005
<Marsh> Can someone update "Sonic" so I can record attendence...
? 2005-06-16: Amy to provide test cases for MEPs not described
in Part 2.
DONE 2005-07-06: Bijan to add text to alt schema examples
DONE 2005-07-14: Arthur will make editorial change to both
DONE 2005-07-14: Arthur to propose or fix/improve description of
import in primer
? 2005-07-14: Roberto find comments Amy proposed to schema
and add them
DONE [18] 2005-07-14: PaulD to roll up LC124
? 2005-07-14: Marsh to send a mail flushing out implementations.
amy ai on test cases: incomplete
bijan to add text to alternate schema examples: sent new version to johnathan. done.
arthur to make changes to syntax summaries for types section to explicitly indicate schema elements (core and primer). done
<pauld> helps if you use a real schema tool instead of a bugged one
arthur to fix/improve description of import. done. tools used by querent are non-conformant as regards import.
roberto to add comments to schema. pending resolution of questions from roberto.
paul to summarize lc124. done
johnathan to send mail flushing out implementations. pending.
johnathan asks about the "fix/improve descriptions" ai to arthur.
explanation of discussion with querent
WSA is proposing week of September 26. Meeting in Bay Area. Possibly Sun hosting.
Call for objections to September 26 week, colocated with WSA. Hugo says: they want 27-28; we would get 29-30.
Umit asks question on summer break in August. Yes, we will be off.
Next meeting will probably be week of November 7; Hitachi has volunteered to host in Tokyo, with other offers from Sri Lanka, London, and Newcastle, Paris, Rennes, Stockholm.
<JacekK> do we need the f2fs so frequently?
some objections raised to expense of working group meetings. other comments made that phoning in needs to be possible.
<jjm> hugo, the above link does not work (forbidden)
further discussion on issues around face to face meeting.
johnathan notes that charter expires in january; we need to be close to pr, or expect not to be renewed.
more discussion of logistics.
Hugo suggests that some comments have gotten pushback from commenters.
LC 75f. Extension attributes on RPC local element children. Agreed with comment, closed with no action on grounds that spec doesn't prevent. Commenter objected, pointing out text.
<hugo-proj> http://lists.w3.org/Archives/Public/www-ws-desc/2005Jul/0045.html\
Multiple proposals for resolution exist (link pasted by Hugo)
Umit, Roberto suggest that this is editorial, a clarification that describes original intent.
<scribe> ACTION: Editors to incorporate amended proposal from Johnathan as regards LC75f resolution (attributes for RPC) [recorded in http://www.w3.org/2005/07/20-ws-desc-irc]
<Marsh> ACTION: Marsh to respond to all comments. [recorded in http://www.w3.org/2005/07/20-ws-desc-irc]
Johnathan: wants to vote to go to LC by end of day tomorrow, but we need to know exactly what we're voting on.
<Marsh> http://lists.w3.org/Archives/Public/www-ws-desc/2005Jul/0071.html
LC 76c. Propagation of faults, clarified, objection from reviewer.
Resolved by addition of a security considerations section. Text proposed by Johnathan and Amy.
Argument over last sentence.
<hugo-proj> Proposal:
<hugo-proj> [[
<hugo-proj> 2.4 Security Considerations
<hugo-proj> Note that many of the message exchange patterns defined above describe
<hugo-proj> responses to an initial message (either a normal response message or a
<hugo-proj> fault.)
<hugo-proj> Such responses may be used in attempts to disrupt, attack, or map a
<hugo-proj> network, host, or services. When such responses are directed to an
<hugo-proj> address other than that originating the initial message, the source of
<hugo-proj> an attack may be obscured, or blame laid on a third party, or may
<hugo-proj> enable or exacerbate denial-of-service attacks.
<hugo-proj> Security mechanisms addressing such attacks may prevent the delivery of
<hugo-proj> response messages to the receiving node. Conformance to the MEP is
<hugo-proj> measured independently of these security mechanisms.
<hugo-proj> ]]
Tony and Arthur provide modified final sentence.
<hugo-proj> New last paragraph:
<hugo-proj> [[
<hugo-proj> Security mechanisms addressing such attacks may prevent the delivery of
<hugo-proj> response messages to the receiving node. Conformance to the MEP is
<hugo-proj> measured prior to the application of these security mechanisms.
<hugo-proj> ]]
<Marsh> +1
<hugo-proj> RESOLUTION: Close LC76c with:
<hugo-proj> [[
<hugo-proj> Security mechanisms addressing such attacks may prevent the delivery of
<hugo-proj> response messages to the receiving node. Conformance to the MEP is
<hugo-proj> measured prior to the application of these security mechanisms.
<hugo-proj> ]]
<hugo-proj> oops
<hugo-proj> with:
<hugo-proj> [[
<hugo-proj> 2.4 Security Considerations
<hugo-proj> Note that many of the message exchange patterns defined above describe
<hugo-proj> responses to an initial message (either a normal response message or a
<hugo-proj> fault.)
<hugo-proj> Such responses may be used in attempts to disrupt, attack, or map a
<hugo-proj> network, host, or services. When such responses are directed to an
<hugo-proj> address other than that originating the initial message, the source of
<hugo-proj> an attack may be obscured, or blame laid on a third party, or may
<hugo-proj> enable or exacerbate denial-of-service attacks.
<hugo-proj> Security mechanisms addressing such attacks may prevent the delivery of
<hugo-proj> response messages to the receiving node. Conformance to the MEP is
<hugo-proj> measured prior to the application of these security mechanisms.
<hugo-proj> ]]
<scribe> ACTION: part two editors to incorporate text for section on security considerations, as approved. [recorded in http://www.w3.org/2005/07/20-ws-desc-irc]
LC 76d. Objections to ADD. Addressed by restoration of wsoap:header. Objection: mustUnderstand not useful.
<Marsh> DaveO proposes: http://lists.w3.org/Archives/Public/www-ws-desc/2005Jul/0070.html
Discussion of how convincing the defense of mustUnderstand is.
Paul offers use case of a WSDL published by a third party; service actually provided by (for examples) members of a consortium.
Paul then suggests that this is not necessarily a strong use case, solvable by policy as well.
Questions: why is this in here? Various people: Dave O wanted it in to handle the versioning use case, which others criticize as weak.
Johnathan: general case of marking incompatible versions not solved. This doesn't help for that general case.
... mustUnderstand doesn't solve a real problem; the real problem that it tries to address is much larger.
Glen: postpone discussion until Dave Orchard is available for discussion.
Hugo: have vocal group suggesting that this be removed; need defense from Dave Orchard prior to vote.
<hugo-proj> Noah's proposal: http://lists.w3.org/Archives/Public/public-ws-desc-comments/2005Jun/0003
LC 91. Text on import/include text. Not clear whether commenter's response was "musing out loud" or a serious objection to the work done.
Hugo: should we accept this revised text? only drawback may be verbosity.
Discussion of what Noah's comment means. Does it mean that we are not working the way that schema works? Or not?
Johnathan: there are two different levels.
Arthur: two issues. 1) need for import. 2) resolution
... if processor resolves a QName, ever, it can resolve it forever.
... offers to clarify issue
Hugo: Noah satisfied, but offered possibly "clearer" text. However, many in WG find clarification very obscure.
<scribe> ACTION: Arthur to investigate LC 91 and Noah's proposed rewording [recorded in http://www.w3.org/2005/07/20-ws-desc-irc]
LC 96. WSDL import semantics are not the same as xs:import.
<uyalcina> I want to go into the record saying that my reading of his comment suggests that there is a difference between the way we treat importing embedded documents in WSDL (LC91).
Arthur will also look at LC 96.
<Roberto> /me "The principle purpose of import is not to import
<Roberto> components
Break for sanity recovery.
<youenn> la task description me va. On ne peut pas etre bcp plus precis dans ce transparent
<youenn> a l'oral par contre, il faudra sans doute donner des precisions
<youenn> je t'envoie par mail quelques precisions
meeting resumes
LC 84b. Operation name mapping requirement (best practice now) has wrong granularity; resolved with no action except explanation in primer. Objection reiterates need for per-message action, but is willing to accept decision.
Johnathan: matter of timing and division of labor. Umit: can be done via addressing, and we mention addressing.
No action taken.
Hugo: wsoap:action set at operation level, sets the Soap:action feature, but don't specify on what. Glen: in general, setting at op level sets on all messages, but could be clarified.
<hugo-proj> http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20-adjuncts.html#soap-operation-decl-relate
<scribe> ACTION: editors to clarify that setting wsoap:action sets the soap action property on all messages in operation. [recorded in http://www.w3.org/2005/07/20-ws-desc-irc]
Hugo and Umit suggest a problem of granularity with wsoap:action.
<uyalcina> wsoap:action is at the operation level, WS-A WSDL binding document allows actions to be set at the message level. We need to clarify whether there may be an interaction issue later.
LC 72. Faults which are not described in WSDL may be received. Closed with no action. Response from objector: how do you know that a response is a fault?
Glen, Amy: it's up to the binding.
Umit: thinks he wants to be able to distinguish between declared and undeclared ones (ref to part two)
anish: is this to help distinguish, from receiver's point of view, between undeclared fault and undeclared other message?
amy: yes, that's what he's suggesting for part one, and for part two, as umit suggests, he's recommending greater specificity.
roberto: not clear that the "undeclared faults" *will* always be of the same class as declared faults.
umit: disagrees, his undeclared faults are only interface-level (application) faults
roberto, amy: then his assumptions are faulty.
general consensus: let's not do anything about this one.
hugo: summary is that there is no easy way to classify these unclassified faults; if they could be declared they would be declared.
<uyalcina> I actually do not disagree. Rereading the message, I agree with Roberto.
<uyalcina> the intent seems to capture the protocol level problems as well.
<jjm> no objection*
LC 72 to be returned to objector with the summary agreed; if faults aren't characterized, then we can't usefully offer further guidance in the specification.
Return of the Schema LC issues! Starring Arthur!
Arthur: our intention is to be consistent with Schema behavior as regards import and include.
... LC 96. Text in spec talks about "importing components". We should instead talk about "licensing references to components in foreign namespaces". The location attribute must resolve to foreign namespace WSDL.
... we are "pervasive" (discussion of term, which glazes scribe's eyes).
<hugo-proj> Noah's proposal for LC96: http://lists.w3.org/Archives/Public/public-ws-desc-comments/2005Jun/0004
Amy: reluctant to accept wording submitted.
... suggests that the language uses XML Schema WG "terms of art" current only within that WG.
Hugo: which text does this supplement or replace?
<Zakim> alewis, you wanted to ask for action to editors on cardinality/optionality of location attribute on wsdl:import/wsdl:include
amy's issue with optionality of location attribute dropped on presentation of evidence of optionality as far back as 2003.
Amy proposes that the clause containing "visibility" and "pervasive" be dropped, as incomprehensible.
Arthur: wants editorial action to clarify that an import has two functions, licensing reference, and actually making components available.
<scribe> ACTION: editors to incorporate the proposed text from Noah for LC 96 into section 4.2 of part one. [recorded in http://www.w3.org/2005/07/20-ws-desc-irc]
Arthur: LC 91. In agreement with spirt of his suggestion.
Amy: don't like his text, thinks as a clarification it only obscures.
Arthur: explanation of comment.
more discussion of the details of how import works.
<Arthur> umit - see part 1 3.1.2 Inlining XML Schema
roberto: there is an issue here, ways in which we are not consistent with XML Schema semantics.
umit: let's acknowledge a difference. replace "with some additional restrictions" in section 3.1.1 by "with the following additional restrictions"
<hugo-proj> The WSDL import element information item is
<hugo-proj> modeled after the XML Schema import element
<hugo-proj> information item (see [XML Schema: Structures],
<hugo-proj> section 4.2.3 "References to schema components
<hugo-proj> across namespaces"). Specifically, it can be used
<hugo-proj> to import components from WSDL descriptions that
<hugo-proj> do not share a target namespace with the importing
<hugo-proj> document.
<hugo-proj> As with XML schema, each document making references
<hugo-proj> to components in a given (foreign) namespace MUST
<hugo-proj> have an import for that namespace (but not necessarily
<hugo-proj> providing a schemaLocation identifying the document
<hugo-proj> in which the referenced component is declared). [In
<hugo-proj> other respects, the visibility of components is
<hugo-proj> pervasive;] if two WSDL documents import the same
<hugo-proj> namespace then they will have access to the same
<hugo-proj> components from the imported namespace (I.e.
<hugo-proj> regardless of which, if any, schemaLocations
<hugo-proj> are provided on the respective imports.)
<hugo-proj> Proposal: in Core section 3.1.1, replace "with some additional restrictions" by "with the differences defined in this section"
<scribe> ACTION: editors to replace "with some additional restrictions" in section 3.1.1 by "with the differences defined in this and the following section" [recorded in http://www.w3.org/2005/07/20-ws-desc-irc]
<hugo-proj> Proposal: in Core section 3.1.1, replace "with some additional restrictions" by "with the differences defined in section 3.1.1 and 3.1.2"
<hugo-proj> ACTION: Marsh to reply to Noah about LC91 saying that our spec already covers his concerns [recorded in http://www.w3.org/2005/07/20-ws-desc-irc]
The return of LC 76d.
Deferred until David is present to defend presence of mustUnderstand.
Hugo: wg members generally said: use cases presented not compelling.
David: mustUnderstand allows the client to instruct the receiver (service) that that note is required for processing.
... reiterates use cases, particularly revving version
Glen: for another example, multiple services implementing different versions of a published WSDL
David: seems logical that WSDL allows this directly, not policy.
Amy: don't find use case compelling
David: reiterates use case.
... isn't always the case that the service controls the wsdl or revs the service at the same time as the wsdl.
glen: profitable comparison between new service with changes to body?
paul: not the same. can add elements in different namespace in body; can't do to headers.
david: this is simplest case, when service provider controls wsdl, namespaces, and service code.
... when any assumptions break down, then the wsdl author needs to be able to use mustUnderstand on headers.
roberto: two cases, out-first, where commnunicates to client that the header must be supported. second, where there is external wsdl author to service provider.
david: there's no way to force everyone to update when a wsdl is updated. however, can update the wsdl to require a required header.
umit: seems that you have to have two versions of contract. both supported by one endpoint?
david: true only when service controls wsdl publication; not true when client controls or participates in wsdl publication.
umit: still not convinced by the use case.
hugo: doesn't appear that positions are changing here.
... nervous about removing something that exists in wsdl 1.1, when one person is arguing so strongly in favor of it.
... Summary: comment about ADD solved by replacement with wsoap:header. Commenter objected to mustUnderstand: in order to accept, must either explain or remove.
<dorchard> shouldn't the be phrased as a change to the status quo?
Tom: WSDL lets you do things that are stupid, this is another one, that some people want.
david, since the original commenter initiated the change of events, probably not.
hugo: others in favor?
Arthur: need a test case, at least.
<dorchard> status quo, drop, add primer
Straw poll: leave spec as is, include example in primer; or drop support for mustUnderstand
umit: third option, leave in mustUnderstand, but don't add text to primer.
straw poll: keep mustUnderstand or lose it?
results: seven in favor of keeping; five in favor of losing.
<scribe> ACTION: dorchard to respond to commenter on keeping mustUnderstand [recorded in http://www.w3.org/2005/07/20-ws-desc-irc]
break for one hour: return at 1:30, to speak about lc 124.
straw poll results modified: four in room opposed.
<dorchard> ok
<scribe> Scribe: youenn
we are back
hugo: two agenda topic
umit: before LC124, new information about LC76d
... no wsoap:header@mustUnderstand in WSDL1.1
anish: only way to set mustUnderstand in WSDL1.1 was to put it in the schema component
hugo: we should then take another strawpoll on LC76d
<Marsh> http://www.w3.org/TR/2001/NOTE-wsdl-20010315
daveO: you could set it through schema.
anish: yes but there is no wsdl binding specific construct for setting it
hugo: in WSDL1.1, we could do it through schema. In WSDL20 status quo, we could set it at a higher level
jmarsh: should we add the constraint that soap:header referenced type must allow extension attributes
... ?
... what about conflicts when setting mustUnderstand at the binding and schema levels
... status quo seems currently broken
<Marsh> DaveO says that's a general problem with any type used for headers.
<Marsh> And I suppose I agree.
daveO: this abstraction is nice to cope with soap 1.1 and 1.2 versions
hugo: who would like to keep @mustUnderstand + tweaking ?
<Allen> I vote to not keep it
4 voted for
<charlton> I vote to remove it
9 voted to remove it
daveO: with WSDL2.0, we have two soap versions while in WSDL1.1, we only had one. It would be simpler in WSDL2.0 to set it in one place.
hugo: who cannot live without wsoap:@mustUnderstand ?
daveo cannot live with it
hugo: who cannot live with wsoap:mustUnderstand attribute ?
roberto: I object as long as wsoap:mustUnderstand attribute is not fixed
jmarsh: what about a header type which disallow soap:mustUnderstand ?
glen: this is an issue for XML Schema./XMLP group
daveo: we need to do something there
<Roberto> roberto: my objection is based on the fact that we haven't resolved the potential conflicts between the schema for a header and the soap:mustUnderstand attribute that may be forced on the header.
<Roberto> roberto: specifically, doing anything that would make headers schema-invalid is objectionable
<umit> +1
anish: we took the decision (literal vs. encoded use) that the schema tells you what the xml looks like on the wire.
hugo: we should add something in the spec about this issue
jmarsh: in the wsoap binding, we should add lines that say that schema elements referenced from wsoap:header should or must be attribute extensibles.
glen: this is a more generic issue and we may want to add guidelines
anish: in dave proposal, are the schema elements always need to support attribute extensibility or only in the case the wsoap:@mustUnderstand is set ?
daveO: in all cases, people that are creating schema elements to be used as soap headers should allow attribute extensibility
glen: this is related to LC124. There is something in the message that is not described in the message
daveo: wsoap:@mustUnderstand is good because it is at the right layer (the binding) and not at a wrong layer (the types)
anish: and what about actor and role soap attributes ?
daveo: @mustUnderstand is much more used than @actor and @role
... wsoap:header was added in lieu of the add feature. In that use case, @actor and @role are not really relevant.
anish: today, I can set @role using schema
<dorchard> Proposal: deal with attribute/element extensibility in LC 124, and deal with wsoap:mustUnderstand as part of 76d
<charlton> +1
roberto: I am afraid of closing 76d based on the result of LC124 future discussions.
<dorchard> As part of 5.10.3, new sentence "This element SHOULD be extensibile with attributes, such as SOAP attributes".
roberto: we should say that if we are using wsoap:@mustUnderstand in a way that contradicts header schema definition, then this is an error
<dorchard> This element represents a SOAP header block.
<alewis> I could suggest: "Schema elements intended for use as SOAP headers SHOULD be extensible with SOAP attributes."
roberto: I objected because of the possible conflict between schema and wsoap:header@mustUnderstand.
<dorchard> Schema elements intended for use as SOAP Header blocks MUST be extensible with SOAP attributes.
<Marsh> Concerned about testability of MUST, but willing to sort that out during CR.
<hugo-proj> Proposal:
<hugo-proj> [[
<hugo-proj> Schema elements used as SOAP headers in wsoap:header declarations MUST be extensible with SOAP attributes.
<hugo-proj> ]]
<dorchard> I'll point out it's a fact that "SOAP Header blocks that MAY fully utilize the SOAP processing model (including role, mustUnderstand) MUST allow SOAP extensibility"
anish: I object to the MUST, because this was allowed in WSDL1.1
<hugo-proj> Proposal 3:
<hugo-proj> [[
<hugo-proj> Schema elements used as SOAP headers in wsoap:header declarations with a @wsoap:mustUnderstand value of "true" MUST allow the soap:mustUnderstand attribute with the value of "true".
<hugo-proj> ]]
hugo: if we do not agree on proposal 3, let's jump to LC124
... who is uncomfortable with proposal 3 and keeping @wsoap:mustUnderstand ?
glen: proposal 3 is only a fix to a much more general problem (LC124)
daveo: why not accepting this proposal and revisit LC76d after resolution of LC124 ?
tom: proposal 3 is too specific (only @wsoap:mustUnderstand). Proposal 2 (extensibility for all soap attributes) seems more appropriate
Hugo: let's go to LC124
paul is making a summary of LC124 issue
http://lists.w3.org/Archives/Public/www-ws-desc/2005Jul/0088.html
paul: we are a big schema user but we (the web service community) are not using it to validate messages (primary goal of schema wg) but to describe messages
... the schema wg wanted to produce a "angle bracket" description of the XML. Then the web service wg came and wanted to reuse their work
daveo: this is an implicit design rule of XML Schema.
paul: schema wg was quite surprised about the way people were using their product
paul summarizes PSVI and the validate twice technique
rebecca: how does the validate twice technique resolves the problem ? It removes the additional data, it does not describe it better.
paul talks about another versionning technique using xs:any
v1 is: <sequence><element firstName/><element lastName/><any/></sequence> is ok
v2 is: <sequence><element firstName/><element lastName><element middleName minOccurs=0/><any/></sequence> is not ok because of UPA constraint
paul: therefore the validate twice technique seems more appropriate
umit: where is the bar between using message compatibility and using different namespaces ?
... just putting additional element data can break compatibility
daveo: henry's technique (validate twice) is only one particular technique. There are other techniques (xmlbeans in apache).
<umit> Let me clarify. Using namespaces is one way of indicating incompatible change, or can be used as a major version.
daveO: we should not enshrine one particular technique with our proposal
<Zakim> alewis, you wanted to comment and request that issue be separated into two
tony: the validate twice technique has a limitation. If we add some content that has a known schema, the PSVI will not be unknown. We will not be able to throw this content.
arthur: can we specify what is additional content ? The validate twice technique was a definition for that but this technique is not applicable in all cases.
paul: we have an issue with a solution (validate twice) but this does not invalidate the issue
arthur: I am sympathetic to the issue. if we can specify an interoperable solution for this problem, this would be nice
... henry's technique requires the elements to be global elements not local.
amy: we are strongly opposed to make ignoreUnkown=true the default behaviour.
<TomJ> y
amy: we would like the discussion to be divided in 1) enabling this behaviour and 2) if enabled, decide what would be the default behaviour
... another requirement from our side is that additional content need to be direct child(ren) of the root element (am I right, amy ?).
paul: we could define an attribute that tells that a particular mechanism is engaged.
... this way, the particular technique could be defined later on.
... I would like to have a way to engaging/communicating this mechanism
<alewis> tibco feels that the current description allows the defined message content to be "wrapped" by "unknown" elements, and fears that the cost for processing/implementing of allowing wrappers would be very high.
umit: we want to have a well defined mechanism and not to rush in
tony reexplains arthur's example about the validate twice limitations
arthur: the goal of the algorithm is to identify the additive content to throw out.
... in some customers scenarios, this algorithm fails to identify this additive content.
daveO: would you be more confortable with ignoreUnexpected ?
arthur: yes, we would like an unambiguous algorithm to identify all additive content to throw away. Henry's technique is a partial solution for this problem but does not cover all scenarios.
amy: a partial solution will not make us happy
arthur: henry's technique only works with global elements. It does not seem to cover enough scenarios.
daveo: has a response to that comment (not really understood from the scribe)
<charlton> dave - could you summarise your comment for youenn?
daveo: We should do the minimal step, therefore doing the ignoreUnkown and not the ignoreUnexpected.
glen: V2S should not be the default behaviour.
... in the same way we want to support element extensibility, we would like to support attribute extensibility which are used for instance for soap headers
... if we can specify a validate technique in english, easy to implement, let's do it, even if it is not completely aligned with XML schema 1.0
roberto: having this technique the default behaviour may slow down the acceptance of WSDL 2.0. On the other side, having a versioning solution within WSDL 2.0 may speed up WSDL2.0 acceptance
... we need to keep this feature on track.
... making it an extensibility point may make this never be done
hugo: I feel a bit weird to put the ignoreUnknown in the core spec when we do not add support for interesting scenarios (the ignoreUnexpected-igonreUnknown ones).
<dorchard> Glen, was your objection that ignoring unknowns isn't enough, it must be ignore unexpected?
<Arthur> should be ignoreNotKnown since [validity]=notKnown
hugo: if V2S is not enough and it seems the case, we could come up with another uri for another algorithm
<dorchard> It's factually incorrect to say "when this first came up it was about unexpected". Every single time I have talked about this in the past 3 years has talked about an unknown element. For example, middle name is an undefined type and then added into name.
amy: proposal: add a hook to say "we are using this algorithm to do validation", make the default to strict, add a V2S uri and call for volunteers.
<dorchard> where does the hook go?
<kliu> including ignore unknown, unexpected,..."
arthur: support amy's proposal. We have at least two processing style: strict and V2S. V2S is a precise algorithm that covers some cases. It is better than nothing.
<kliu> if group is heading to the uri direction,
<kliu> I would prefer something like wsdlx:schemaProcessingStyle= "xs:anyuri"
<kliu> wsdl should only provide a pointer,
<kliu> let people define whatever validation/versioning mechnism they want to use
daveo: given that there is at least two interpretation (ignoreUnknown and ignoreUnexpected), BEA can live with a processingStyle attribute (default=strict), this attribute being in the core.
<kliu> , including the ignoreUnkown, unexpected, etc,
glen: I prefer adding a boolean ignoreUnexpected switch than having a @processingStyle
<dorchard> BEA can live with: 1) wsdl:validatingStyle="uri" with default== strict and unknown=no type available or 2) wsdl:allowUnknowns="boolean" with default="false" and unknowns=no type available.
<dorchard> I think sonic likes a version of the 2nd where unknowns="no type in content model".
roberto: I like the hook idea. default=strict should not mean we must validate all messages.
<Zakim> TomJ, you wanted to object to not just having a boolean
<umit> +1 to Roberto, default=strict should not mean we must validate
<charlton> +1 to Roberto
tom: I agree with glen that adding a uri hook is not good. It affects interoperability. I prefer a boolean switch with a well defined behaviour.
... If we cannot define this behaviour precisely enough, we should not put this in the spec.
<kliu> +1 to Tom if we treat the boolean as an extension.
<pauld> proposal on the whiteboard: http://www.flickr.com/photos/psd/27410949/
hugo: we could add the @processingStyle in the core and the V2S as an extension.
<dorchard> I like the fact that schema gives us a single attribute for "notFound", which hits a good set of use cases.
arthur: defining extra content is tricky, not impossible. That is why it should be a uri and not a boolean. V2S is a starting point. The full solution will take a huge effort.
... this is the same as mep.
<umit> +1 to Arthur
daveo: we should at least have one mandatory style
<Zakim> dorchard, you wanted to mention that I think the ignore unexpected will be harder than people think. You have to rewrite the schema processor to throw out unexpected things until
anish: similar feelings as tom and umit. My main concern is schedule.
daveo: ignoreUnexpected is an invasive change. V2S is simple as it does not impact the schema processor.
umit: we could put this in the core with one defined uri (the strict). We could also add in the adjunct spec the V2S technique.
<alewis> +1 to umit
umit: the default attribute value would be the strict uri.
<dorchard> FWIW, BEA would object to any of: 1) flag in extension, 2) adding any/all algorithms in extension and no mandatory algorithm(s)
<dorchard> BEA's prefers ignoreUnknown as mandatory value, but we can be moved off of that to get consensus and sure we don't get to the objectionable points...
roberto: the proposal does not deliver any benefit to our users as V2S is not the practical choice.
... UPA can help us in defining what is the additive content.
<dorchard> Here's another "unexpected": <name><first/><first/></name>? Do you ignore the first or the second first?
<GlenD> yeesh :)
<charlton> sorry, i've got to drop off now - cu tomorrow
roberto: I want the hook, the strict value as the default and progress on the ignoreUnexpected definition
<dorchard> what about <first><last><phonenumber>?
umit: my proposal is to add a hook, but we are not defining any uri for V2S, only for the strict processing style.
anish: what about a proposal ?
hugo: three proposal:
... 1)ignoreUnknown proposal (not ignoreUnexpected) based on V2S
<pauld> chad, question: options for LC124
<pauld> chad, option 1: SV2
2) ignoreUnexpected (on/off switch)
<pauld> chad, option 1: 2VS
<dorchard> So "ignoreUnexpected" converts every maxOccurs into maxOccurs="unbounded"
<pauld> chad, option 2: ignoreUnexpected switch
<pauld> chad, option 1: V2S
3) the hook proposal with variations
4) close the issue
<pauld> chad, option 0: shoot outselves in the head
<GlenD> dave... hm - that's an interesting point.
<pauld> chad, option 3: hook proposal with variations
<alewis> vote: 2, 3, 4
<pauld> chad, option 0: close with no action
<pauld> chad, options?
<alewis> vote: 2, 3, 0
<dorchard> vote: 1
<Roberto> vote: 2, 3, 0
<Allen> vote: 2, 1, 3
<RebeccaB> vote: 0,2
<GlenD> 2,1,0
<umit> vote: 3, 0
vote: 2,1,3
<TonyR> vote: 2, 3, 0
<Arthur> vote: 3, 2, 0, 1
<GlenD> vote: 2,1,0
<pauld> chad: 2, 3, 1
<hugo-proj> vote: 3, 2, 1, 0
<TomJ> vote: 2, 0, 1, 3
<pauld> schema is deterministic
<anish> vote: 0, 2
<dorchard> I have a doctor's appt that I have to leave for in 5 minutes.
<alewis> chad, count?
<chad> Question: options for LC124
<chad> Option 0: close with no action (2)
<chad> Option 1: V2S (1)
<chad> Option 2: ignoreUnexpected switch (8)
<chad> Option 3: hook proposal with variations (3)
<chad> 14 voters: alewis (2, 3, 0) , Allen (2, 1, 3) , anish (0, 2) , Arthur (3, 2, 0, 1) , dorchard (1) , GlenD (2, 1, 0) , hugo-proj (3, 2, 1, 0) , pauld (2, 3, 1) , RebeccaB (0, 2) , Roberto (2, 3, 0) , TomJ (2, 0, 1, 3) , TonyR (2, 3, 0) , umit (3, 0) , youenn (2, 1, 3)
<chad> Round 1: Count of first place rankings.
<chad> Candidate 2 is elected.
<dorchard> which happens to be a main reason why I'm not in boston.
<chad> Winner is option 2 - ignoreUnexpected switch
<alewis> chad, details?
<dorchard> Rebecca, this is why I voted for #1.
<dorchard> I am violently opposed to option 0
<hugo-proj> Cannot live with
<hugo-proj> 0: 2
<hugo-proj> 1: 4
<hugo-proj> 2: 1
<hugo-proj> 3: 1