W3C XML Protocol Working Group teleconference, 5 June 2002

Derived from IRC +Log

1. Roll

Present, 27/21 Excused Regrets Absent

2. Agenda review and AOB

7 items remaining on the agenda:
Approval of May 29 telcon minutes [0] (12.40 + 5)  
Review action items, see [1] (12.45 + 5)  
Status reports. In general, reporters should be able to describe what is  
GETF report (1.15 + 30)  
Shall we publish the Part 1 and Part 2 documents [2] and [3] as WD's?  
Comments against Test Collection docs (1.45 + 15)  
LC decisions(2.00 + 30)  

  f2f host is Software AG


3. Approval of may 29 minutes


4. Action items

<Yves> Editors: DONE
<Yves> Editors: DONE
<Yves> Editors: pending( was first Editors AI)
<Yves> MarkB: Pending
<Yves> Yin Leng & PaulD: DONE
<Yves> Yin Leng: DONE
  df: thanks to Yin-Leng and PaulD for work on charmod review


5. Status reports

  primer update: no news
  df: update available when?
  nilo: couple of weeks
  df: GETF discussion will highlight some changes needed in primer
  conformance: can we cover that under #8?
  ak: yes
  usage: john's not here
  email: no updates
  media type: markB not here


6. GETF Report

  df: noah?
  nm: GETF on rush program to produce a proposal, discussed architecture issues w/http binding and RPC issues
  nm: few days ago GETF drafted me to integrate the changes into the spec, cf helped with HTTP binding and MEP
<DavidF> re. primer update - nilo simply signalled he will be available over the next couple of weeks
  nm: all changes made and handed off to hfn to incorporate email comments
  nm: should we go into architectural points?
  df: yes please:)
<DavidF> "a little bit of architecture would be a good thing"
  nm: introduced sections covering 1) call out simple feature that describes "web methods", references HTTP spec (GET, POST, PUT, DELETE, etc.)
  nm: suggests you should use GET or POST
  nm: useful independent of RPC
  nm: 2) RPC layer, based largely on proposal I circulated one or two weeks ago
  nm: should know which arguments identify the resource as distinct from those that represent state
  nm: when you use RPC on the Web, you SHOULD, where practical, make sure that identifying information appears in the URI
  nm: we don't say how that encoding should be done
  nm: take a step back
  nm: we used to have one MEP - request/response
  3) added new MEP called SOAP response
  nm: if operation you are doing is "safe" retrieval, no body to be sent, no headers, etc. then RPC is sent using new MEP, use new feature to specify web method GET
  nm: other circumstances, use request/response and POST web method
  nm: anything else?
  hfn: no, good enough
  df: notes that document is very shortly forthcoming to WG for review/approval
  jacek: what is status of consensus of the name of the new MEP
  df: consensus in GETF is that it will be called "SOAP Response"
  Jacek: have expressed some concern that it may carry some significant data
  nm: it does
  df: does that answer your question
  jacek: yes

  df: here's what we're suggesting we do in terms of rolling this out
  df: see my email on additional info for agenda item #7
  df: we think this is about ready to go to TAG, signal to them that we'd like a fast turnaround
  df: suggest we ask for review by this time next week
  df: send heads up email to TAG today
  is email under discussion
  df: we'll go through comments/concerns and roll into a document based on current ed-copy snapshot
  df: tomorrow pm, WG can see fully integrated version of part 2
  df: as ed copy
  df: WG is encouraged to look at that, evaluate it and if you need to make a decision as to whether this should go to a wider audience... e.g. this document represents a consensus
  df: if I don't see any negative comments on the list, i'll inform the TAG
  df: is that schedule okay with WG?
No objections raised. Chair asserts the schedule is OK with the WG.
  df: one additional point, WG gets 'til Tuesday to get any specific feedback and we deal with those on telcon next week
  df: I'll ask WG if the disposition of the comments and document are ready to go out as LC WD
  df: TAG, we really need to make sure they get a chance to review (monday is when they meet)
  df: is that okay?
  nilo: its really part 2 that we're talking about, not primer changes, right?
  df: correct
  df: one of the things that GETF will have to do in short order
  df: GETF to figure out what goes in primer on tomorrow's call
  df: has been some concern expressed as to need for education
  df: first part of plan is to get closure with WG, GETF and TAG
  df: need to figure out how to handle conformance document
  df: we really just arrived at this point, still trying to figure out what all of the implications are
  df: going to take silence as acceptance of first part of plan
  df: critical part is WG review comments due by Tuesday EOB
  df: to editors, can we make changes with change bars in it?
  hfn: yup
  nm: we're not doing anything beyond what style sheet used today? not 100% reliable
  nm: style sheet needs to be updated
  mh: I can hack that tomorrow
  nm: great
  df: I'm hearing no pushback on comments on revisions in time for next week's telcon
No objections raised.
  df: i take that as acceptance by WG then
  ak: will hacked stylesheet show diffs in tables?
  mh: yup
  df: going to need to figure out how to cascade changes to conformance and primer
  df: i am disinclined to do that now, take off line with editors of various documents


7. Publish parts 1 and 2 as WDs.

  df: shall we publish current part1 and part 2 as WDs?
  df: unclear to me (before) how long GETF would be able to address the TAG issues, really concerned to get closure so stuff didn't dribble in and out of those docs
  df: given we've agreed to plan for GETF, i am inclined now NOT to pose question, because i think it'll take time away from them cranking through GETF changes
  df: on other hand, if TAG can't respond with their comments for 2 weeks... are there any opinions from the WG?
  hfn: as one of the editors with limited amount of time, strongly encourage us not to publish
  hfn: not sure who customers of such a WD would be... docs already ~public as editors draft
  df: anyone feel strongly that we should publish now?
  df: okay, move on to #8


8. Comments against test collection

  ak: don mullen's comments incorporated
  ak: put in significant amount of editorial changes, that's current status. not published as yet
  ak: issue 194... spec text says something different than resolution
  ak: encoding style attribute allowed on SOAP elements
  hfn: we came to pretty clear resolution that it may not
  ak: but spec doesn't say that explicitly sect 5.1.1
  hfn: fwiw, think it is reasonable to write it up more clearly, but...
  jjm: don't think it was me who put it in
  mh: could have been me
  ak: is this included in current ed copy?
  hfn: yup
  ak: don't see it
<DavidF> http://www.w3.org/2000/xp/Group/2/05/31/soap12-part1-1.128.html#soapencattr
<DavidF> is 5.1.1 in 31 may
  hfn: i think that's right, whther it would be useful to say MUST NOT appear, I'm fine with that
  df: so what's there is okay, but clarification that it must not appear elsewhere is okay?
  hfn: yes
  df: URI points to section we're discussing
  df: anyone unhappy about adding line to 5.1.1 saying MUST NOT appear elsewhere
  mh: for consistency, we've been saying where things *can* go, not where they *cannot*
  df: why then is it an issue for this particular test?
  ak: because resolution text says something different
  df: can we change the assertion in the spec text to say "MAY ONLY appear ...."?
<DavidF> changing "The encodingStyle attribute information item MAY ONLY appear on:"
  df: any objections?
Chair asserts the WG has agreed to make the change to the spec.
  ACTION 1=Editors to fix assertion in 5.1.1 to say MAY ONLY or something like that, to better reflect the spirit of issue 194 resolution that can be tested as an assertion
  ak: thinking of adding section about...???
  hfn: yes, there's a bunch of choices to be made...
  hfn: think we have to be careful
  df: I'm confused
  hfn: rpc:procedure not found e.g. says MAY, but we don't say what's right way to do it
  nm: occasions where spec says you MAY but if you do you MUST do it this way
  ak: agree with noah
  df: e.g. if RPC used, then assertion
  ak: not exactly, we say that it is not required for conformance
  df: so there's just a blanket statement in beginning that says ...
  df: one way to categorize which tests are obligatory and which are not
  ak: at beginning of collection, add paragraph which lists things like procedure not present, fault reason and mention that these are in the test collection, but conformance to the collection, you don't have to use these values
  hfn: or things like reason, and others that are used in specific tests?
  hfn: think that is editorial
  ak: but issue you raised applies to more than procedure not present
  df: unless there are other opinions, suggest we leave this as editorial decision, you deal as you think best
  df: other questions for anish?
  df: <puts on scheduler hat>
  df: what's timeline for rolling these changes into test collection doc?
  ak: Lynne and I think that EOD saturday, we should be able to roll these changes in, is this okay?
  ak: this doesn't include GETF changes
  df: right
  df: would be super useful to look at what impact GETF would have on test collection
  df: wonder if there are people on call that could volunteer to review GETF changes and noodle on how that would impact test collection
No one volunteers.
  nm: one of the decisions we reached this morning was to take some of the SHOULDs and make them mushier
  nm: takes these off the table
  nm: do we have tests that test binding, like HTTP binding?
  ak: yes
  nm: for MEPs or features?
  df: some of RPC tests may disappear?
  nm: don't think so, just in new sections we've added
  df: i see
  df: back to the original question, think it would speed us up lots if someone could look at what we publish tomorrow and figure out what might be needed to change
  df: please contact me directly after the call, otherwise we'll have to serialize this activity
  ak: question w/r/t spec version, currently synched up with 31-May, do editors know when next version will be available?
  df: the only changes to the 31-May version will be GETF
  ak: looking at ed copy and do see changes in there, wondering if these are w/r/t 31-May or changes w/r/t 14-May
  hfn: there was one issue we found today, change yes to true has been fixed, only change I know of
  df: so that's the only diff between 31-May?
  hfn: yes
  df: 31-May is stable version?
  hfn: yup
  df: other questions? otherwise expect to see revised test collections doc over w/e
  ak: yes
  ACTION: Lynne and Anish to publish new test collections doc over this w/e


9. LC decisions

  df: okay, on to LC decision
  df: number of things we need to figure out
  df: and other types of information we need to capture, see #9, 4 subparts
  df: I) a list of documents for LC, also listed type (e.g. WD, ID, etc.) and type of review we are requesting and comments to be sent
  df: we need to agree that is what we are going to do
  II) list of groups we are asking feedback from
  df: want to know if that's the right list
  df: III) we are going to try to go from LC to PR skipping CR, so we need to provide right evidence of impls
  df: need to signal our intent to the world
  df: and conditions under which WG will make that jump
  IV) announce for LC review needs a date when period ends, suggests date
<Noah> Do we have implementation issues with the new RPC and HTTP GET stuff?
  df: we can do this via email or now
  df: or next week
  nm: think its in spirit of this to demonstrate GET ala GETF changes
  nm: (MEP and RPC suggestions/recommendations, etc.)
  df: in terms of impls??
  nm: yes
  df: lets wait to we get to III
  nm: okay
  df: okay, I)...
  df: re Parts 0, 1, 2 of the spec, I guess that's noncontroversial, any comments?
Chair asserts the WG has decided to accept the publication of Parts 0,1,2 of the spec as stated in the agenda.
  df: re. test collection, any comments?
Chair asserts the WG has decided to accept the publication of the Test Collection document as stated in the agenda.
  df: i believe with that decision we can close issue #36 whcih we had deferred until we decided to publish the Test Collection document
  df: agree to publish test collection
  ACTION 3=DF to send closing text for issue #36 to xmlp-comments
  df: re. the "Email Binding" document, we publish it as Note, but we don't specifically ask for comments
  df: note the change to its name, and its publication as a Note...
  df: any objections?
  df: i take that as agreement
Chair asserts the WG has decided to accept the publication of an Email Binding document as stated in the agenda.
  df: next proposal is that we mention in our LC announcement that we plan on writing a non-normative document during LC that describes an attachment feature... we decided this a while back
  hfn: we don't promise we'll be done, do we?
  df: was going to say "we plan to create"
  hfn: we plan to start work?
<Noah> How about we plan to consider deciding whether to start thinking about possibly creating an attachments document?
  df: i'd like to signal that we plan to complete work
  hfn: no particular reason we want to say we have another spec ready
  df: you're using words like spec, making it sound bigger than I intended
  df: imagine it would be a Note
  hfn: well...
  df: would you be happier saying by Recommendation?
  hfn: yes, that would be fine
  okay by me
  df: okay then, any other comments?
  df: next, we make reference to appl/soap+xml ID
  df: mb would not submit to IANA until we had a stable namespace URI
  hfn: also because we didn't know whether GETF impacts this or not
  hfn: little tricky
  hfn: might very well be that we're ready to move forward with SOAP1.2, but have cross dependency with IANA
  df: okay, I'll take this one out then, and we'll bring it back later
  hfn: okay
  ACTION 4= Chair to chat with Mark B to figure out what to say about ID in LC announce
  df II) list of WGs
  cf: suggests add XKMS and XMLEnc
  cf: also asks if webont is part of S/W
  yl: says yes
  df: okay, we'll add these two (XKMS and XML Enc)
  nm: how bout TAG?
  df: okay, I'll add TAG
  df: thanks, on to III)
  df: exit criteria for advancing to PR
  df: this doesn't guarantee we move from LC to PR
  df: one friendly amendment, jacek points out that it should say there are two, interoperating and different implementations of all non-optional features
  df: any other comments?
  nm: more as a warning to ourselves, w/r/t GETF and RPC changes...
  nm: hope we would see implementation experience during LC, warning should be if we want to get out of LC, we need to see implementations.
  jacek: so you are saying we should list things we want to see implemented and those we don't?
<DavidF> s/all non-optional/non-optional and optional/
  nm: text df has proposed is fine, just reminding the group that last time we looked at this and asked if there were impls, there were a bunch that said that they were very close and if we set this criteria (then) we could achieve our objective. just reminind the WG that the changes for GETF weren't part of that consideration
  jacek: don't want to see us leave LC without some impl experience
  df: we wouldn't meet out exit criteria then
  df: we could have our exit criteria only mandatory features
  df: any objections to accepting revised text as exit criteria?
Chair asserts the WG has decided to accept the text in the agenda and as amended by Jacek's recent email.
  df: okay then
  df: if we get towards the end of july, we have option for extending LC period
  jacek: or go to CR?
  df: becomes academic at that point
  jacek: agree
  df: on to IV) really just a note that we decided to hold a f2f last week of july
* JacekK notices that iv) does mention CR. 8-)
  df: we really want to finish the week before
  cf: that was me
  df: that would put end of comment period july 19
  df: that makes for 5 week LC period
  df: okay?
Chair asserts the WG has decided to accept end of LC as being July 19.
  df: that's all she wrote, we can adjourn early unless there is anything else