XMLP WG Telcon, 27th June 2001
No AOB signalled
DF: David Clay...
DC: With changes we could now do a third version of the module template.
DF: So action stands...
DC: Yes... if we still need a module template.
DF: Schema WG Typelib. DF has sent mail to Schema WG chair. No response; pending
DF: Issue 19 Henrik and Gudge to discuss with originator.
HFN: No closure.
DF: Lets change this action to move your discussion with the originator to dist-app.
DF: Infoset rewrite to Gudge.
HFN: Gudge did send out a re-written section 4.
JJM: Gudge started this in Dinard but wanted approval on a single section before addressing the whole document.
DF: Mark this item as done.
HH: I have been looking at what SOAPBUILDERS have been doing. No new proposal. Still pending.
DF: Issue 30 Paul:
PC: No progress; pending.
DF: Action to Noah to seed Infoset discussion.
Noah: I believe I have done that.
DF: You did send something out.
DF: As I read this action item I think it has a slightly different meaning... synthetic infoset, but also to seed discussion as to why we might move over to using an infoset model.
Noah: "recounts the motivation for the action" plus partial confusion arising from referencing an old Infoset Draft.
DF: Noah's item as done.
DF: Next item was to me -- ensure the question we removed from sec 2.4 is reflected in the issue list. This has been done.
DF: Similarly, the next item which was for the editors to remove the question from 2.4. Done.
DF: Next item to Stuart to send reminder email re. QName. Done.
DF: Next item to make sure that there was a block/header distinction issue on the list. Leave pending.
DF: Next item to include Henrik's version proposal in the spec. Has been done.
<item type="member-only">
Dana joins the call
DF: Abstract model, Stuart
SKW: Addition of acknowlegements section and reference to Hugo's suggestion
DF: Any further questions on AM?
None
DF: My hope is that on the call today that we can resolve enough issues so that we can approve these documents for publication. Can we hear from the editors of the spec.
Marc: Up until 12 hrs ago I thought that we were done. In the last 12hrs we've had quite a bit of feedback, mostly editorial.
HFN: Yes, we've done all that we were asked to do from the F2F.
DF: So... is there much that we need to do to the draft that folks have been reviewing?
Mac/Henrik: There are certainly some edits that we need to do.
DF: Would like to focus on issues arising from F2F. First issues is the 'concise terminology' version. Dug prepared the text and it has been incorporated into the document.
DG: I have a few slight issues. The module word does appear and the recent changes need..
DF: So in order to consider this we need to include in consideration some material that was posted this morning. I'm wanting to be very clear that we're asking folks to approve material they may not have seen.
DF: Are we happy with Dug's text as proposed?
No dissent raised.
DF: ???
HFN: Doug has pointed out that the term module has been removed from the glossary leaving a few dangling references in the document.
DF: Is that an acceptable unseen change?
PD: The abstract model has the term module. Is that an issue?
Noah: I think that after clean up the AM can go places that the spec doesn't go. The notion of module may come back and we need to be able talk about modular enhancements and have a term for that...
PC: Re Henrik's changes he refered to "the" changes and its not clear which of these changes he is refering to.
DF: I'm assuming this is just the references to module.
DF: I think that we're done with the 'concise terminology'.
DF: Now we can move onto the NS/Schema issue. Gudge in cleaning up the spec has picked up an ambigity between open and closed content model for fault. is there discussion?
HFN: I would prefer a closed model.
SKW: How will schema be published.
DF: In parallel with the spec.
??: What is the reason for keeping the model closed.
HFN: We have detail which is open. I would like to avoid the same
Chris Ferris: I don't know how you can say that you know what it (the fault message?) means.
HFN: If something arises at the same level as
DF: Does anyone object to us making the fault element a closed content model?
CF: I think I need more time to think about this.
DF: If we find ourselves unable to decide then the fall back is to the inconsitent form in SOAP 1.1
PC: Ugh...
DF: Do you object to the publication with a closed content model.
CF: No...
DF: Here's a proposal: option "c" from agenda, but leave the issue unresolved on the issue list so that we can revisit it later.
Unanimous consent
DF: Another issue which I've pointed out: Namespaces for envelope and upgrade block. The NS's in Gudges note are BOTH w3c.org namespaces.
DF: I hear no comment on Gudge's flag.... we'll move on from that.
CF: Would it be more extensible for the future to avoid echo back using envelope version that you receive and it would avoid having to make reference to a particular namespace in the spec.
HFN: What it says now is that you always use the 1.1 envelope.
CF: Hmmm... no I think that you (can?) echo back with an envelope matching that which you received.
Glen: That is also a problematic with maintaining knowledge of multiple versions in the case of changes in envelope semantics.
Marc: Refer's to a note in appendix C that mark this as a proposal that may change to become more generic.
Marc: Discusses Henrik's further changes to 4.1.2 that correct inconsistencies between 4.1.2 and appendix C.
DF: Just focussing on Appendix C: are we ok with appendix C.
No dissent
Marc: In section 4.1.2 there is text that describes the envelope versioning model. When appendix C was added the text at 4.1.2 was not updated to reflect the mechanism of appendix C. Henrik's changes fix that.
DF: All clear? Do we all agree that this needs to be done?
No dissent
DF: This now seems to be an editorial task... so we'll take those suggested changes to
Marc: Some changes on header blocks, body blocks, header entries, body entries... consistent changes to a header and body blocks.
DF: Any further changes?
HFN: Yes a few more editorial around the use of the term "node".
DF: Jean-Jacques are you happy with that?
JJM: Yes
HFN: In section 2.2 I added a sentence about there being no routing semantics.
Noah: I like the general sense of this. I like the first sentence. I find the second sentence a little obscure. The 2nd sentence seems a little more specific than we need to be. We could drop it or we need to clean it up a bit.
DF: So is the proposal to drop it or to modify it. I propose that we drop the 2nd sentence.
No dissent
Chris: I have sent out at least a grammatical change to the 1st sentence which I would like considered.
DF: I'll leave this to the editors discretion.
HFN: There are more... in the last sentence in 2.5(?) I have added some words about unrecognised elements after the Body(?)
Noah: ...does it deal with the encryption case...
HFN: I think that this is a slightly different question. Your edits didn't make it in... your edits deal with headers....
[missed discussion on encryption case etc.]
DF: Henrik can we omit that last sentence of 2.5 and include this in the general discussion of trailers which remains an open issue.
HFN: Ok.
HFN: Example 5 this should show an example of an authentication fault code. I'd like the text below to explicitly mark it as an example.
DF: Regard as editorial.
DF: Stuart you also sent in some comments.
SKW: Most are typos and regarding the others, I wouldn't make them an obstical to publication.
DF: Do we have the WG's consent to send these documents modulo these changes to the W3C?
CF: The issue that I raised this morning about the HTTP extension framework. Seems a little strange to publish the document with something that we're going to remove.
DF: I'd also draw attention to an issue that calls out that the document is *not* real crisp about what is and what is not normative.
Noah: This is a WD and it's a useful heartbeat and it can change....
DF: Back to Chris.
CF: I think I understand, but I think that when we publish something as high visibility as this I'm uncomfortable to include things I don't really believe in. I'm uncomfortable about the potential for interop problems.
DF: We have an immediate problem that we're out of time. I'd appreciate folks staying on the call a few more minutes.
Everyone agrees
DF: We have a couple of options here. We can excise the HTTP Extension framework....
PC: Is there an issue in the issues list?
DF: Yes... it's in the issue list (as of this morning)
PC: I think that that should be enough.
Marc: I think that Chris is right becuase folks won't read the issues list and we should take it (HTTPD Extension ref) out and I'm happy to do that.
DF: Comments from another editor please?
HFN: It is mentioned several places.
CF: I've done a quick scan and I think it's relatively easy...
HFN: This would be a bigger issue if this were the very first time that this document has been made public. I doubt that folks will read this any different form the equivalent pieces of 1.1
HH: There is a point where we just have to go with what we have.
Richard Martin: Echo Noah's comments on purpose of WD.
Paul D: If you remove it you will get comments from folks that care.
Noah: Could we just invite particular feedback.
DF: Chris, would it be acceptable to solicit feedback on this?
CF: Yes... I take it that that would mean an in-line question.
DF: We have tended to move in-lines to the issues list and to solicit feedback on the mailing lists... Chris can you live with that?
CF: I'd prefer inline, but could live with a message to the list.
Action to chair to work with Chris to construct such a message.
DF: So... returning to the earlier question is there any dissent on us submitting these documents to the W3C for publication modulo the changes we have agreed?
No dissent.
DF: Congratulations.... we have our WDs
DF: We're out of time I will take item 7 Transport Binding Architecture to email. Thank you all.