Minutes of XMLP WG telcon on 15 October, 2003.
1. Roll call.
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,
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
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
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.
-- 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
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
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".
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
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
- 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
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.