Derived from IRC +Log
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) AOB f2f host is Software AG
<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
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
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
http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2002Jun/0043.html
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
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?
silence
df: okay, move on to #8
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
looking...
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?
silence
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?
none
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
silence
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
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? prolly 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? silence 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? silence 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? silence 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? Silence. 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? silence 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? silence 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