Based on IRC log
1. Roll Present 12/10 BEA Systems, Mark Nottingham BEA Systems, David Orchard Canon, Herve Ruellan IBM, David Fallside Microsoft Corporation, Martin Gudgin Oracle, Anish Karmarkar SAP AG, Volker Wiechers SeeBeyond, Pete Wenzel Sun Microsystems, Marc Hadley Systinet (IDOOX), Jacek Kopecky W3C, Yves Lafon (scribe) W3C, Carine Bournez Excused Canon, Jean-Jacques Moreau Microsoft Corporation, Jeff Schlimmer Oracle, Jeff Mischkinsky SAP AG, Gerd Hoelzing Sun Microsystems, Tony Graham Systinet (IDOOX), Miroslav Simek Regrets DaimlerChrysler R. & Tech, Mario Jeckle IBM, John Ibbotson IBM, Noah Mendelsohn Absent DaimlerChrysler R. & Tech, Andreas Riegg IONA Technologies, Seumas Soltysik IONA Technologies, Mike Greenberg 2. Agenda Review [ScrYves] Agenda: http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2003Oct/0034.html 3. Approval of Minutes [ScrYves] Minutes of Oct 15 approved. 4. Action Items [ScrYves] DavidF: SVG group pinged, no response yet. We will work on generic MTOM and reping SVG -> pending 5. Status and Misc. [ScrYves] Status: [ScrYves] -> review of Character encoding approved (Jacek version with Noah's modification) [JacekK] ACTION 1= JacekK to send the response to Character Entity proposal to Michael and XML Plenary list w3c-xml-plenary@w3.org [ScrYves] Mime type registration: no news [ScrYves] David: is that surprising? [ScrYves] MackN: no [ScrYves] - WSD response, see AI list [ScrYves] - Generic MTOM [ScrYves] MarkN: question was "should we make it generic so that other group might reuse it? [ScrYves] MarkN: rewritten in a SOAP-neutral way [ScrYves] MarkN: the only technical work is a way to hint the format. There is currently a hardwired assumption. to make it generic, we should have a way to say it's a SOAP envelope or a SVg document, etc... [ScrYves] Gudge: agree with Mark in general, wonder if the document will move outside of this WG (if it becomes general) [ScrYves] MarkN: going outside may link to explosion of requirements [ScrYves] DavidF: we need to coordinate with other groups anyway, so it would be ok to keep the work in our group [ScrYves] MarkN: processing model issue at the mime level, the information about the type of the document might disappear if we have this general wrapping [ScrYves] MarkN: it should have a specific mime type and a resulting mime type (at least) [Gudge] so for SOAP this would be (currently) specific == multipart/related and resulting == application/soap+xml ? [ScrYves] <Yves> multipart/related -> application/mtom+xml -> application/soap+xml, no? [Gudge] Dunno, can't tell from the discussion... [ScrYves] DavidF: WG will go forward with MarkN's suggestion [ScrYves] ACTION: MarkN to fork the MTOM spec per his Generic MTOM proposal by Nov 3 [ScrYves] 6. Attachments [herve] Updated version of use case: [herve] http://lists.w3.org/Archives/Public/xml-dist-app/2003Oct/0057.html [davidF] An application wishes to send a SOAP message that contains one or more [davidF] redundant binary pieces of data. Each redundant binary piece of data is [davidF] actually contained in several locations of the SOAP message (for [davidF] example, the SOAP message could contain an XML document which includes [davidF] in several locations the PNG logo of the company which authored the [davidF] document). For design reasons, this data cannot be referenced [davidF] externally, but must be transported with the message. Doing so by [anish] looks fine to me [davidF] replicating each redundant binary piece of data as many times as it is [davidF] contained in the SOAP message involves an unacceptable message size, due [davidF] to bandwidth, latency and/or storage requirements. [Gudge] +1 [ScrYves] All: looks good [ScrYves] -> will be incorporated in the SOAP OS UC & Reqs document [ScrYves] ACTION: UC req editors to add Herve's use case version 1.1 as UC6 or UC (n+1) [ScrYves] - ednote from Mark Jones in sec 4.3 [ScrYves] "We have removed requirements having to do with serialization part ordering. Such requirements may be added pending use case analysis. [ScrYves] " [ScrYves] Gudge: will we renumber the use case? [ScrYves] also whould we give the list of all the removed UC? [ScrYves] DavidF: we have a out of scope use case section, that we might remove at some point [ScrYves] DavidF: do any or our UC have any relation to part ordering? [ScrYves] proposed solution, add a note to UC 12 saying that it might have indication for part ordering [ScrYves] Yves: ednote about ordering, while UC12 is about interleaving, not really related [anish] +1 [ScrYves] DavidF: proposal to remove the ednote [ScrYves] no objections -> ednote deleted [ScrYves] ACTION: UC req editors to remove ednote in 4.3 [ScrYves] DavidF: any objection to publish this doc as a WD? [ScrYves] no objection [JacekK] ACTION 7= W3C Staff and Chair to submit the UC and Reqs doc for publication as a WD [ScrYves] * issue 441 [ScrYves] Marc: if uses as intended, we won't have base64 any longer, so not apply [ScrYves] Gudge: has schema published the canonical form? [ScrYves] DavidF: no news [Gudge] ACTION: Gudge to ask XML Schema WG about the status of base64 canonical form ( is it public? ) [davidF] http://www.w3.org/2000/xp/Group/xmlp-issues.html#x441 [ScrYves] resolution: it must be in canonical form, and in the schema one [ScrYves] issue 441 closed [ScrYves] ACTION: Gudge to send closing email wrt issue 441 [ScrYves] http://www.w3.org/2000/xp/Group/xmlp-issues.html#x432 [ScrYves] proposal, close issue 432 by noting that 441 implies that items to optimize must be in base 64 canonical form [ScrYves] no objections -> issue closed [Gudge] ACTION: Gudge to send closing e-mail WRT issue 432 [ScrYves] http://www.w3.org/2000/xp/Group/xmlp-issues.html#x435 [ScrYves] Marc: a resolution would be "it can't" [ScrYves] proposal: "SOAP receiver cannot determine which elements were optimized" [ScrYves] no objections -> issue closed [Gudge] ACTION: Yves to send closing e-mail on Issue 435 to xmlp-comment and originator [ScrYves] http://www.w3.org/2000/xp/Group/xmlp-issues.html#x436 [davidF] 431 was closed with text at http://lists.w3.org/Archives/Public/xml-dist-app/2003Aug/0025.html [ScrYves] Pete: closing for 431 was text from noah added in section 2 [ScrYves] DavidF: should we close 436 by referencing the text in 2.4.3? [ScrYves] Pete: yes [ScrYves] Marc: issue 440 is about sharing mtom part at leaf nodes, need to think about 436 in the light of 440 [ScrYves] Marc: is it ok to have copies instead of a single copy? [ScrYves] DavidF: proposal to close 436 in light of 431 and keep 440 separate [ScrYves] proposal: close 436 by referencing the text in 2.4.3 and 2.4.4 [ScrYves] no objections -> closed [ScrYves] ACTION 12= PeteW to send closing email on issue 436 by referencing text in 2.4.3 and 2.4.4 and decision on 431 [ScrYves] http://www.w3.org/2000/xp/Group/xmlp-issues.html#x440 [ScrYves] Marc: is it ok to include the same attachement in multiple place in a SOAP message? [ScrYves] Gudge: Paswa, an include refers to exactly one part. [ScrYves] Gudge: need to reference using URIs if you want to do multple inclusions [ScrYves] Gudge: in the representation header [ScrYves] DavidF: Noah suggest that only one include can point to any mime part [anish] we just agreed to including the redundant binary obj usecase [ScrYves] also ask if it would be ok for a smart mtom impl to do so [ScrYves] Anish: how this affect the redundant binary use case? [ScrYves] Gudge: use the representation header to do so [ScrYves] Marc: OK with what is suggested but if we go that route, we need a std way to reference the representation header [ScrYves] Gudge: in paswa, it's done using URIs [ScrYves] Marc: more a representationref type [ScrYves] Gudge: don't want to use multiple way to reference things outside r inside the envelope [ScrYves] DavidF: Marc, you want an attribute that will have a URI but a representation header? [ScrYves] s/a/a reference to/ [ScrYves] DavidF: Marc, you want an attribute that will instruct the binding to look the URI in a representation header [ScrYves] DavidF: need to see a proposal for providing this mechanism [ScrYves] Gudge: wondering if the representation header is done to do what Marc wants [ScrYves] Gudge: representation has been designed to address the cached URIs issue [ScrYves] -> no resolution [davidF] ACTION: marcH to kick-off email discussion of issue 440 [ScrYves] ADJOURNED [RRSAgent] I see 11 open action items: [RRSAgent] ACTION: JacekK to send the response to Character Entity proposal to Michael and XML Plenary list w3c-xml-plenary@w3.org [1] [RRSAgent] ACTION: MarkN to fork the MTOM spec per his Generic MTOM proposal by Nov 3 [4] [RRSAgent] ACTION: UC req editors to add Herve's use case version 1.1 as UC6 or UC (n+1) [5] [RRSAgent] ACTION: UC req editors to remove ednote in 4.3 [6] [RRSAgent] ACTION: W3C Staff and Chair to submit the UC and Reqs doc for publication as a WD [7] [RRSAgent] ACTION: Gudge to ask XML Schema WG about the status of base64 canonical form ( is it public? ) [8] [RRSAgent] ACTION: Gudge to send closing email wrt issue 441 [9] [RRSAgent] ACTION: Gudge to send closing e-mail WRT issue 432 [10] [RRSAgent] ACTION: Yves to send closing e-mail on Issue 435 to xmlp-comment and originator [11] [RRSAgent] ACTION: PeteW to send closing email on issue 436 by referencing text in 2.4.3 and 2.4.4 and decision on 431 [12] [RRSAgent] ACTION: marcH to kick-off email discussion of issue 440 [13]