Web Services Description WG
7 Oct 2004

 

<dbooth> Scribe: Anish

Approval of Minutes

last weeks minutes -- approved

Review of Action items

3.  Review of Action items [.1].  Editorial actions [.2].
 
PENDING   2004-04-01: Marsh will get schema tf going.
DONE [.3] 2004-08-04: Jonathan to check the policy with AB
                      and team and perhaps set
                      up a ML for testing.
PENDING   2004-09-02: Bijan to create stylesheet to generate a
                      table of components and properties.
DONE [.5] 2004-09-09: Roberto to classify our errors as fatal or
                      non fatal. (LC5f)
DONE      2004-09-15: Hugo to investigate potential options for
                      get the Zed version published in W3C
                      web site.
DONE      2004-09-15: Jonathan to ask XForms folks to review
                      WSDL.
  Response: Should have comments next week.
PENDING   2004-09-16: Editors to move App C to RDF Mapping spec,
                      except the frag-id which will move
                      within media-type reg appendix.
PENDING   2004-09-16: Editors to fix paragraph 6-9 of section
                      2.1.1 moved into 2.1.2
                      which talks about the syntax.
PENDING   2004-09-16: Hugo to get a URI to use for DTD example
                      in Appendix E.1 (LC38)
PENDING   2004-09-16: Glen to CC Asir on mail to Marc re: SOAP modules
                      and features (LC18, LC29b)
PENDING   2004-09-30: Marsh to ask Glen about how LC9 is going.
DONE [.4] 2004-09-30: Jonathan to contact XMLP to review the Media
                      Type Description document in order for us to
                      go to LC with it.
PENDING   2004-09-30: Working Group to review Media Type note in
                      preparation for LC vote next week.
PENDING   2004-09-30: Arthur to add Z notation to Part 1.
 
[.1] http://www.w3.org/2002/ws/desc/#actions
[.2] http://www.w3.org/2002/ws/desc/4/lc-issues/actions.html
[.3] http://www.w3.org/2004/06/29-testcases
[.4] http://lists.w3.org/Archives/Public/xml-dist-app/2004Oct/0001.html
[.5] http://lists.w3.org/Archives/Public/www-ws-desc/2004Oct/0027.html

jmarsh: new policy on IPR for test cases. we need to decide whether our test cases should be a rec or something else

<dbooth> (JMarsh to fill in)

arthur: problem with the z-notation validator

arthur/hugo looking into it

jmarsh: pl. look at the IPR policy

hugo: xmlp wg published the test suite as a rec. the problem with that is that it is hard to update

jmarsh: our charter does not list the test suite as a rec, but we are not under the new patent policy
... for xmlcore we have not made it a rec

arthur: what is the mech for people to contribute test cases -- would there be call for that, would it be on the ML?

jmarsh: folks on the wg can contribute directly to cvs. The contributtions will be covered by the patent policy. For non-members we can ask them to sent it to public comments lists

paul: trying to put together a test suite -- policy doc is very useful. Will try to put it in cvs.

arthur: suggestion -- paul should set up the dir structure and then publicize it

paul: i do have a good test suite for wsdl 1.1 which i can port it to wsdl 2.0

arthur: how is the mapping between wsdl 1.1 --> wsdl 2.0 going to take place?

paul: those tests will be something to start with

paul/hugo to set up the directory structure

jmarsh: i propose that we don't try to shoot for a rec status on the test suite so that we have the ability to update it regularly
... our charter does not call it out as a rec

arthur: rec would be too heavy-weight. I would like the ability to continuously evolve

jmarsh: your companies legal folks may have an opinion on this

roberto: what does continuously evolving test suite mean for conformance?

arthur: i don't think we should be making a claim about conformance based on the test suite
... i think of it mostly as guidance
... we should have version numbers

roberto: we need to have a vehicle for releases

jmarsh: when we feel that we have made significant changes we can make an update

davidb: it is important not to confusing conformance with passing the test suite. it is not definitive.

anish: If you pass the test suite, you are not necessarily conformant to the spec, but you can claim conformance to the test suite itself.

roberto: i don't recommend going down the rec path either

media type desc

jmarsh: we should not do anything this week, folks should review it. A new issue has come in on the TF ML. We can take it up next week. XMLP WG will finish their review next week.
... lets postpone the vote till next week

issues

jmarsh: ed issues, ed should incorporate the fix or come back to the WG with a fix -- delegated to the editors

no objection to doing this

issue LC5f

jmarsh sumarizes roberto's email

<Marsh> http://lists.w3.org/Archives/Public/www-ws-desc/2004Oct/0027.html

roberto: there are few things that are left out. for instance xml schema import or a desc would be just errors, they can try to recover from this
... there are some implications on the schema validity of the whole doc

<Arthur> +q

jmarsh: so validating to our schema will be just an error

roberto: y

arthur: it is true that schema does not enforce strict validation on extension.
... i would be in favor of saying that the doc should be at least valid
... the processor should not keep on trucking even if the doc is not valid

jmarsh: there may be a invalid binding which one can ignore

arthur: understanding a binding is different from a valid binding

<sanjiva> are we talking about being schema valid???? If so I'm definitely against requiring that wsdl docs be schema valid

<sanjiva> if I'm off base I apologize

arthur: we should at least require that the doc is valid

roberto: if u can write a process that can recover that is great -- should not be disallowed

arthur: i don't want to get into a situation similar to the browser

roberto: i don't want to get into a situation where my cellphone has to validate some goop that it does not care about

arthur: if the doc is not valid u should not have to process it

jmarsh: it is an error

sanjiva: lot of applications allow well-formed doc which are not valid to be used

arthur: it should be a burden on the author of the doc to make it valid

jmarsh: not-valid is an error

roberto: non-conformance with the schema -- results are undefined
... this should not require the processor to fault

arthur: it is upto the created to ensure that the doc is valid

<Zakim> dbooth, you wanted to ask for clarification about what Roberto means by "valid" -- valid against the WSDL schema?

roberto: we should not ask the processors to schema validate the part that they do not care about

davidb: roberto -- what is meant by valid? to the wsdl spec or the extension schemas? Or the message being exchanged?

roberto: wsdl schema. for extension we have wildcard with processContent='lax' so no requirement to validate extensions

sanjiva: i don't want to require every wsdl processor to validate every schema

arthur: the processor does not have to validate every doc, the processor should assume that it is valid

jmarsh: the processor may detect an error and recover from it
... a processor may not even get to the faulty part
... let us look at roberto's proposal. any more questions on the proposal?
... let us look at it in 2 weeks. arthur -- if you find an ammendment that satisfies your concern -- send that out

LC29b

jmarsh: dup of 18
... outstanding AIs on this. Skip over it

LC30

{jmarsh reviews the issue}

sanjiva: this is a case of two editors wanting different terms
... we have a consistency problem. I'm not convinced that the community uses these terms
... i would like to use the terms used in majority of the spec and clean up any inconsistency

jmarsh: the alternative would be to -- to fix the consistency -- we could use "* agent"

asir: we could use sender/receiver

davidb: these terms do appear in more places that sanjiva realizes. We have part 1, 2, 3 + primer. They do appear in bunch of places

JJ: part 3 did not use it

<asir> i see provider agent in part 3

anish: can we talk about what the right term to use is rather than counting the number of times they occur

jmarsh: we can take a straw poll?

arthur: what about the primer?

davidb: we decided to use 'agents'

dbooth: the term 'client' does not appear in part 1 at all

asir: i see 'server' and 'sender' twice

davidb: i don't think sender is a problem

jmarsh: we can standardize on one term. we could use one term in the base doc and use a simplier term in the primer. The other way around seems a little strange

davidb: i would suggest consistency throughout
... no 'client' in part 2. Only xform client appears in part 3
... no conflict on the term 'client'

sanjiva: i want to remove the term 'requestor agent'

roberto: +1 to sanjiva

<asir> + 1 to sanjiva

jmarsh: let us separate parts 1,2,3 and primer

<TomJ> +1 to sanjiva

two options:

<Marsh> option 1) requestor agent/provider agent

<Marsh> option 2) web service/client

<sanjiva> +1 to consumer

<pauld> +1 to consumer

dbooth: the arch wg spent a lot of time on this

<Marsh> option 2) web service/[consumer | client]

<HelenC> +1 to option 1

hugo: even though the arch doc is a note, the wg felt that it had to introduce those terms as other terms were ambiguous

sanjiva: i don't know of any other doc that uses those terms

<prasad> +1 to option 2 (client / consumer based on context requester/responder sender/receiver etc. :)

davidb: on the arch WG i was a strong proponent of 'client', but now i would like consistency

option1: 6, option 2: 10

davidb: if this is what the WG wants to do, not going to lie down on the road

no objections to using option 2

no objection to changing the terms in primer

<scribe> ACTION: editors of parts 1,2,3 and primer to use the new terms

issue 30 is closed

LC45

jmarsh reviews hugo's proposal -- http://lists.w3.org/Archives/Public/www-ws-desc/2004Sep/0049.html

jmarsh: option 2 was getting more traction?

hugo: y

no objections to accepting option 2

issue 45 is closed by adopting hugo's option 2

LC17

asir: there is a proposed resolution

no objection to adopting the proposed resolution for LC17

LC19

asir introduces the issue

sanjiva: u can use the fault component in the interface and inherit it

arthur: i would be opposed to this
... no need to make it a top level thing

prasad: main concern is the reusibility of fault -- since we have a solution -- the requestor of the issue would probably be happy with that

jmarsh: either there is a better way to do this or a work around. The work around is not as direct as the requestor of the issue wants it to be
... work around is to use inheritance as suggested by sanjiva

asir: when u map it to programming languages it does not work
... i don't see there is an issue with the binding and sanjiva agrees

sanjiva: the other solution is to make operation a top level thing
... there is no reason for eg java to say -- take each fault and make it an exception

arthur: if u carry the language binding issue to the logical conclusion then u would remove the fault from the interface and make it a top level thing only.

asir: that is what i'm requesting

prasad: I don't think i agree with that

asir: the faults will be at the top level component, there will be fault ref at the operation and bindings

arthur: the fault ref is like a throws clause

tom: that sounds like a big change quite late in the game. Not convinced that there is an advantage

david: i would prefer that we did not decide on this change today

jmarsh: let us return this to the list, let people mull over

arthur: i think it does impact the binding, if fault is a top level thing would you not have to binding it
... u would have to say how the binding binds faults

prasad: don't see a usecase for: u bind interfaces and faults go hand-in-hand with that

jmarsh: the question is -- does the binding needs to be reworked

<Zakim> sanjiva, you wanted to explain how it affects the inheritance model

sanjiva: it also affects the inheretance model

arthur: usecase would be -- if u make it toplevel, in the org a fault has been identified across interfaces, then u would want to bind it in the same way
... the discussion should include the binding. the proposal should include the binding too

<Marsh> ACTION: Asir to detail binding changes or justify why they aren't necessary (LC19)

LC20

asir explains the issue

<TomJ> I recalled that a we had discussed this before and the 'lower' features couldn't change upper declarations

{more discussion on scoping rule/composition rule}

asir: at the london f2f we discussed scoping but not composition
... LC27 should be considered with this issue

jmarsh: we are out of time, i will ask glen about this issue

adjouned