Actions recorded on IRC.
Present 15/13
No comments and no objections to approval of minutes.
DavidF: Approved.
[http://www.w3.org/2000/xp/Group/Admin/#pending]
-- Part 0
Nilo is not present, but he did send update mail:
http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2003Mar/0051.html
Jean-Jacques: Primer is in sync with Parts 1 & 2.
DavidF: Primer should now follow the same rules of change as the other
parts.
-- Part 1
Editors: Nothing to report.
-- Part 2
DavidF: Strange characters (at-signs or boxes, depending on the browser
used) appear in Part 2.
Yves will help fix these problems.
Editors: Nothing else to report.
-- Test Collection
Anish: Sent status to list:
http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2003Mar/0056.html
The Test Collection doc is in sync with Parts 1 & 2. The only
differences since F2F are the change from valueType to nodeType, and
a bugfix for T59 (id and ref attributes were not in the SOAP
encoding namespace).
-- Registration of "application/soap+xml" media type, see
http://www.w3.org/2002/06/registering-mediatype.html
Yves: Mark Baker & I will publish updated version and submit to IANA,
within a matter of days.
-- n11n publication
(Covered in Action Items portion of agenda; no further comments.)
-- IPR
Yves: Nothing to add.
http://www.w3.org/2000/xp/Group/xmlp-cr-issues.html
-- CR implementation report, see summary table at
http://www.w3.org/2000/xp/Group/2/03/soap1.2implementation.html#features.
The table currently (25 March) shows 6 features for which we have not yet
accumulated sufficient evidence. There is an implementor's telcon tomorrow
prior to the XMLP WG telcon, and that meeting will produce a more detailed
report on the expected schedule to complete the remaining features. At this
time, we do know there will be no more implementations of nodeType in the
near future, and so we will decide how to handle evidence for it. We will
decide how to handle evidence for the other features based on the
implementor's report.
DavidF: Implementors have traces for all but 3 features. 2 of these
are in progress and should be complete by Monday, except for 79
(NodeType) and part of 77.2 (DuplicateID). Implementors will
double-check that traces capture all features and are complete (by
Monday). See email summary of today's implementors telcon:
http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2003Mar/0058.html
WG must decide how to handle NodeType. The choices are:
1. remove nodetype from spec, or
2. leave in and inform W3C that it is too early for implementors to
test interop of this feature. If we receive pushback, we could
remove it, but this would cause the namespace to be changed.
Straw poll: 1 for removal (but no strong objection to leaving it in),
5 for leaving it. No objections to proposal #2 (maintain status
quo).
DavidF: A similar decision may need to be made about MissingID next
week; otherwise implementation evidence for PR is almost complete.
Glen: While testing proper use of the role attribute, there are
differing interpretations of empty string. Some implementations
assume it to be ultimateReceiver, others don't accept it as valid.
Needed from WG:
1. Clarification about what happens when role attribute value is empty
string
2. what to do about it
Text about empty-string value of role was removed per a LC issue (#233).
MarcH: role could be a relative URI (XML Base), so it becomes whatever
the current active base is.
DavidF: What happens if there is no base?
Gudge: We reference RFC 2396, so the question is, does that allow
empty strings? Will investigate. Believes empty string is legal.
"rel_path" consists of any number of characters, perhaps including
0.... Will sort it out by next week.
DavidF: Is it a problem if we don't specify this edge case? It's not
what anyone would generally do. We could target resolution of this
for a SOAP 1.2 Errata. Whatever, we should add it to CR issue list.
-- Issue 419 (http://www.w3.org/2000/xp/Group/xmlp-cr-issues.html#x419),
"SOAP action as property". How shall we handle this WSD WG suggestion? Two
obvious options appear to be (i) ignore, this is too late, (ii) make
change, it doesn't affect implementation status nor is a significant spec
change.
Glen: SOAP "action" parameter, which may be used for routing or other
informational purpose, exists in the media type. Our extensibility
model is in terms of Features, but we don't use our own model to
express this. (There is no WSDL property for setting action
parameter.) Proposal: resolve by adding an "action" feature to HTTP
binding, approximately 3 paragraphs, analogous to Web Method feature.
MarcH: Can see the point of doing that, but does it affect the text in
a negative way at this late stage? It might be too late.
DavidF: Another approach would be to liaise with WSD to address this
in the future as an errata.
Glen: Can see the value of that approach.
DavidF: WG members either doesn't want to change the spec, or don't
understand the issue well enough. Suggest that we postpone this;
hesitant to change the spec at this late stage of the process.
Jacek, Glen, Jean-Jacques: Want to see proposed text before deciding.
Action to produce rough draft of this by end-of-week.
-- pushback on any issues closed?
No pushback received.
-- The promised "single-infoset" approach to attachments has been published in a document called "Proposed Infoset Addendum to SOAP Messages with Attachments", see http://lists.w3.org/Archives/Public/xml-dist-app/2003Mar/0060.html. The WG will consider the approach described in this document, and in time decide whether or not to use the approach as the basis for creating an attachments specification. (Recall that the WG is on record to specify an implementation of the Attachment Feature specification.) Any eventual use by the WG of the approach described in the document is subject to the authors of that document providing appropriate copyright and IP statements to the W3C. Given that the document was published only this morning, the Chair does not expect the WG to reach an immediate decision on whether or not to take up the approach described therein. We will spend time on clarification and discussion of the approach with a view to making a decision at our next telcon (2 April). DavidF: Question to editors of the proposal, is anything in flux? Gudge: The document only lays out a basis for a concrete implementation. We could not just adopt it and be finished. DavidO: The comments received so far are helpful in seeing how everything fits together. MarkJ: Request an informal poll of the authors to see what IP issues may exist; speaking for AT&T, there are none. DavidO: BEA strives to make everything they can royalty-free. Gudge: Microsoft anticipates no problems. SAP: No problems. TIBCO (not present). Jean-Jacques: Canon has no issues. JohnI: This is a good direction. My questions are process-based. How would it fit into the SOAP 1.2 process, specifically interop requirement. Would it begin a separate track? DavidF: Attachment work was established on a separate track from SOAP 1.2, so as not to delay SOAP. It was decided that attachment work would be done as resources allow. JohnI: What is the impact on abstract feature doc? I support a requirement gathering process. Are there any IP links back to the original AF document to those authors who are no longer involved, that would require release (HP, for example)? Gudge: Expects to take both abstract and concrete docs to REC. MarkJ: Concur. AF doc is deficient and needs to be extended anyway. Anish: It was only published yesterday; would like more time to review before continuing discussion. JohnI: Let's reserve time at next week's telcon to walk through it in detail. Yves: W3C believes that this would be in scope for the WG. DavidF: Request that W3C staff read proposal in more detail and confirm that this decision will stand. -- Status report on XMLP WG scope vis a vis "Proposed Infoset Addendum to SOAP Messages with Attachments"t last week's telcon, we started making progress on the attachment requirements listed in http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2003Mar/0027.html. We accepted R19 and R1-5, and ended on a discussion of R13. We will pick up this discussion and continue working through the remaining requirements. DavidF: Continue discussion of R13 from last week's telcon, re arbitrarily large parts. Any new insight? MarkJ: If we incorporate MIME multipart, how do SwA implementations currently behave, just run out of memory when a part that is too large is encountered? Jacek: No limitations; a network stream is provided. Glen: Agree. Suggest that no limitations needed. Gudge: Our implementation also has a mode that provides a stream, so parts may be of any size. DavidF: No objections to postponing discussion. We will revisit this issue when more concrete designs exist. R26, support streaming of parts. MarkJ: Suggest postponing; currently a SHOULD, not MUST. DavidF: Options are to accept as SHOULD or postpone until use cases are generated. Consensus is to postpone. R21, extending metadata associated with whole message packaging R31, extending metadata associated with individual parts DavidF: "Extending" implies that there is metadata to begin with. MarkJ: Maybe change wording to "provide an extensible means of associating metadata with message and parts". Will rewrite these to clarify. -- Any other attachment proposals/issues DavidF: Meeting adjourned.