Minutes of XMLP WG telcon on 15 October, 2003.

1. Roll call.
Present 17/11
BEA Systems, Mark Nottingham
BEA Systems, David Orchard
Canon, Herve Ruellan
IBM, David Fallside
IBM, Noah Mendelsohn
IBM, John Ibbotson
IONA Technologies, Seumas Soltysik
Microsoft Corporation, Martin Gudgin
Oracle, Anish Karmarkar
SAP AG, Volker Wiechers
SAP AG, Gerd Hoelzing
SeeBeyond, Pete Wenzel (scribe)
Sun Microsystems, Tony Graham
Sun Microsystems, Marc Hadley
Systinet (IDOOX), Jacek Kopecky
W3C, Yves Lafon
W3C, Carine Bournez

Canon, Jean-Jacques Moreau
IONA Technologies, Mike Greenberg
Microsoft Corporation, Jeff Schlimmer
Oracle, Jeff Mischkinsky
Systinet (IDOOX), Miroslav Simek

DaimlerChrysler R. & Tech, Mario Jeckle

DaimlerChrysler R. & Tech, Andreas Riegg

2. Agenda review

3. Approval of October 8 telcon minutes

No corrections to the minutes were requested.
Approved with no objection.

4. Review action items

5. Status reports and misc

-- Shall we review the "Character Entity" proposal? See

DavidF: SOAP was specifically noted as something that does not use DTDs,
  therefore it suffers from the problem this paper is intended to address.
  Seeking volunteer to review.
Jacek: This does not pertain to SOAP; I have some personal comments
  that can be sent.
Noah: Have to be careful with this; for example, with dsig, do you sign
  before or after substitution.
Jacek: We should not send these comments from the group.
DavidF: SOAP was called out as a motivation for this proposal; we should
then at least say that it is not relevant to us.
Jacek will take this action.

-- Volunteer sought to review RDF 2nd Last Call docs, see

DavidF: Who reviewed the RDF document last time?
Jacek: Did we respond last time?
DavidF: We should find our previous response and compare our comments
  with changes in this version.
JohnI will do.

-- Proposal for review of OASIS TC's SOAP Message Security,
http://lists.w3.org/Archives/Public/xml-dist-app/2003Oct/0029.html. WG
members should have already evaluated this review, and the Chair is
expecting to ask a simple yes/no question.

Noah: Rich Salz is unsympathetic to price/performance tradeoff of infoset.
  Suggest making a note regarding use of infoset notation throughout
  the document.
MarcH: Unsure what Rich means about not adopting the entire infoset
DavidF: Think Noah's text is reasonable.  We should send in the response
  already drafted, and follow up with Noah's suggestion.
Noah: Propose to include my text in Marc's review.
No objections to this; MarcH will add it and send to WSS before the
  close of the comment period.

-- Registration of "application/soap+xml",

MarkN: No change.
DavidF: For information: until what time can we change the actual name of
  the media type?
MarkN: I think until it is registered. 

MarkN: Message from DavidO; he would like to strengthen wording around
  evolvability and extensibility, and reference TAG finding.
DavidF: Suggest to DavidO that TAG should raise this; this request comes at
  the last-minute and seems out of context from a SOAP point of view.

-- In researching MTOM-like technologies, MarkN discovered potentially
similar requirements on SVG and he suggests a number of possible courses of
action, see http://lists.w3.org/Archives/Public/xml-dist-app/2003Oct/0024.html

Report from binary XML workshop indicated there were similar technologies
being developed.  MarkN suggested 3 courses of action:
  1. Continue with SOAP-only approach.
  2. Participate in work on this outside the WG (similar to XInclude
  3. Do MTOM in this WG, but in collaboration with other groups.
Noah: This shouldn't keep being reinvented, but we need it in time for
  our purposes.
MarkN: Inclined to consider the XInclude approach.
Jacek: Agree with MarkN.
Gudge: Take the fastest approach.
MarcH: Straw poll indicated that using the MIME type was the way to go.
  What happened to that?
MarkN: We haven't yet decided how to split up the doc so its parts are
  generic and reusable.
DavidF: Request proposal to adopt approach #3 and make MTOM more generic.
MarkN: Will propose.

6. Attachments

-- What do we report to the XML Core WG regarding requirements for
XInclude? Decide which response to send from the two listed in

DavidF: Any preference for which version to send to Core WG?  None heard;
  will send DavidF's original message.

-- Use cases, see SOAP OS UC & Reqs document, above
    o UC-6. We decided that this UC needs more precise definition(s), and
that there are multiple possible streaming scenarios that should be
considered. We are first identifying different streaming scenarios and then
choosing one or more of them. Streaming UCs to date are:
        - Interleaving, see

MarkN: Use cases are more general; can rework the example to fit.
Jacek: Favor accepting the use case, but note that we don't intend to
  satisfy it.
DavidF: No disagreement; MarkN to insert the use case, but preface with,
  "This does not mean that we will satisfy the following cases:".  Text
  to be cleaned up at a later date.
MarkN: Thought that the 2nd example, multiple streams, would be the
  only part out of scope.  Suggest that one pair of interleaved streams
  is ok.
Noah: This is a slippery slope.  We should not begin to address it
  unless it can be done easily.
DavidF: Consensus is that we insert the entire use case, and note that
  we don't plan to support it.

        - Large XML data, see

Jacek: Does this incorporate the simple case that the thread began with,
  a single large binary data set.
Herve: No, we should keep these separate.  Be more explicit about
  optimizing "redundant" data.
Anish: UC-9 might cover this.
MarkN: Make UC-9 say "one or more".
Also UC-10.
Anish: Maybe bundle the "redundant" part into UC-2.
MarkN: These are at different levels; references vs. serializations.
Anish: Agree that this is different.
Noah: There are issues with addition, deletion of duplicate references
  and "dangling attachments".  Should be left to the discretion of
  the sender.
DavidF: It would be good to have a redundancy use case.
Herve will write this new use case, to clarify "redundant".
DavidF: No pushback on proposal to make UC-9 and UC-10 handle the
  plural cases.

        - Misc, see

Herve:  The choices are
  1. Make easy for receiver when sender knows length of data.
  2. Make easy for receiver when sender may not know length of data and
    have to buffer and count before sending.
  3. Make easy for sender, don't require knowing length of data in advance.
Jacek: This is more of a design choice, rather than use cases.  We don't
  need these as either use cases or requirements.
DavidF: Any other comments?
MarkN: Should not rule them out.
DavidF: We will discontinue discussion of these.

    o What else needs to be done to the SOAP OS UC & Recs doc before
publishing it?

Jacek: We need to determine whether the use cases generate additional
DavidF: Instruct WG to read UC & Req doc to determine whether any reqs
  should change based on the recent UC changes.  Emails should include
  text, so we can publish this soon. We will go over the UC & Req doc
        requirements at next week's telcon.