XMLP WG Telcon Minutes, 18 February 2004
>1. Roll call. Scribe for minutes selected from attached list. Actions to be
>recorded on IRC. (830PT + 5)
BEA Systems, Mark Nottingham
IBM, Noah Mendelsohn
IBM, David Fallside
IONA Technologies, Seumas Soltysik
Microsoft Corporation, Martin Gudgin
Nokia, Michael Mahan
Oracle, Anish Karmarkar (scribe)
SAP AG, Volker Wiechers
SAP AG, Gerd Hoelzing
SeeBeyond, Pete Wenzel
Sun Microsystems, Tony Graham
Systinet (IDOOX), Jacek Kopecky
W3C, Yves Lafon
BEA Systems, David Orchard
IBM, John Ibbotson
IONA Technologies, Mike Greenberg
Microsoft Corporation, Jeff Schlimmer
Oracle, Jeff Mischkinsky
Sun Microsystems, Marc Hadley
Systinet (IDOOX), Miroslav Simek
Canon, Herve Ruellan
Canon, Jean-Jacques Moreau
DaimlerChrysler R. & Tech, Andreas Riegg
DaimlerChrysler R. & Tech, Mario Jeckle
>2. Agenda review, and AOB (835 + 5)
Agenda reviewed by DavidF.
Jacek: is someone going to take Carine's place?
>3. Approval of Feb 4 and 11 telcon minutes,
>http://www.w3.org/2000/xp/Group/4/02/11-minutes.html (8.40 + 5)
Minutes approved without any objections.
>4. Review action items, see http://www.w3.org/2000/xp/Group/Admin/#pending
>(this item will be skipped and the status of each action listed here taken as
>correct, unless any WG member has a question). These action items are taken
>from the XMLP member page. Some AIs may be discussed under other agenda items.
DavidF: The status of the Actions is as noted in the agenda, except for --
Gudge's action. Gudge did send an email to close issue 456
>2004/02/04: Reqs & UC editors
>PENDING until online copy is updated
>Draft an email to SVG regarding resolution of 452
>PENDING response from SVG, see
>Research on issue 453 (multipart/multiplexed (rfc3391))
>Update XOP spec to say that xop:Include cannot have any children per
>Incorporate Gudge's security section text
>Send an email to xmlp-comments and editors to close issue 444
>Send closing email re. issue 456, to be sent to originator and xmlp-comments
>5. Status reports and misc (8.45 + 15)
>-- Placeholder for pending items
>-- Media types registrations ("application/soap+xml", etc)
MarkN: holding until we figure out xml 1.1 issue
>-- XMLP/WSD Task Force
Anish: no update since the last email that I sent out last week. There has been
a proposal sent and very few emails on the mailing list (4 or 5). Based on
the emails being sent on the WSD ML, it seems like the WSD WG may move the
discussion and review into the WSDL WG. There seems to be a feeling that the
TF will not last as there is no activity. We need to make a decision as to
whether we (XMLP) wants to be involved in the decisions (keep the TF going)
or just review it when WSD is done with it.
MarkN: is Umit going to include the issues that I sent?
Anish: I believe so.
Noah: we still will see what is going on, won't we?
Anish: not if the discussions happen during WSD WG concalls.
Noah: i feel that if we as a WG want to see what is happening, and personally
I think we do, we should tell that the WSD WG should alerts us about this
work and any decisions made around this. We have a dependency on this.
If the best way forward is to use the TF mailing list (even if the traffic
is low) for this then that would be ok. We need a understanding that there
is a shared ML for this.
Jacek: the major problem in WSD is that the TF has no activity whatsoever. It
seems WSD is the more appropriate group to do that. I understand why the ML
should be abandoned.
DavidF: will take it up with Jonathan offline. We would like to be kept in
Noah: i would appreciate if we had some way to interject if we don't like
what is going on. Is the list public?
Anish: the list is public
>-- f2f planning
>See goal statement and draft agenda at
>Comments, other agenda items?
DavidF: we should try to move as close towards LC as possible. The primary
task is issue resolution. If we have proposals for resolutions to consider,
we can then move much faster at the F2F. I did sent out a draft of F2F
DavidF reviews the F2F agenda:
DavidF: local details are in the plenary agenda, registration also managed by
DavidF: do we need a dial up number? (No response) I will send an email to find
out if we need the phone line.
DavidF: one of the agenda item is "any new issue" -- we have been over the mtom
and xop docs a couple of times, notably when we published them as WDs,
recently and in december. Highly recommended that everyone read the docs.
Any new issues can be brought up as a result of such a review. We will not
do a section by section walk thru of the spec.
DavidF: existing issues - cut and pasted from the issues list. The agenda shows
the days starting at 8:30 and ending at 5, but I think we can devote more time
to our meetings. We can have the morning sessions start at 8 and end at 5:30.
The rooms are available from 8 to 6.
Noah: have you checked the breakfast schedule?
DavidF: not directly, but on on wednesday there is a chair's breakfast 7-8:30a
Noah: slight preference for ending at 5:30.
DavidF: agenda has a slot for WG dinner for monday night, are people interested?
General interest expressed by the WG in monday's dinner
The WG has preference to extend the duration of the meeting, DavidF to look at
the breakfast schedule and come to some conclusion (about starting early or
late or splitting the difference)
DavidF: we have slot for 1.2 rec issues -- we could go thru the resolutions
(mostly editorial). We also need to consider the question of soap 1.2.1 or
1.3 which would include the errata.
Anish: is it second edition or a new version?
DavidF: I think it is a new edition, I don't know for sure, I will check.
DavidF: We need to decide what we need to do to go to LC. We won't have the
final text incorporated in the docs after the F2F meeting. That is the stage
that we need to reach at the end of F2F.
>-- XMLP/WSD Joint Meeting in Cannes
>Investigate Wed lunch f2f meeting with ws-desc WG
>PENDING response from WSD, JM has indicated that WSD WG is considering and
>will likely accept
DavidF: the idea has gone down fairly well with WSD. Don't have a definitive
answer yet. We will probably have lunch on wed. Will follow up on it.
>-- Comments on Character Model
>Review I18N's decision on our feedback by next week teleconference.
Tony: not applicable to CharMod as it is now, CharMod is changed in last 2
years. Recommended action is to respond and say that the comments are not
applicable to the CharMod.
DavidF: we should move forward as you suggest. Can we just forward your email?
Tony: I don't think there is a problem with that.
DavidF: so we will be saying that XMLP did not believe what?
Tony: that comments do not apply to changing the CharMod spec, tests should
not be created to conform to CharMod
Noah: Tony is saying that -- charmod says that all w3c recs should test for
charmod, people have pushed back on it. I thought we were saying something
stronger. We could be *much* stronger. There is a TAG issue -- procedural and
technical: can a WG say that everyone should use their spec? I am ok with
Tony's note, but if anything i prefer to make it stronger and crisper. As
long as we don't weaken this I am ok.
DavidF: Tony's note does say that the TAG is looking into this. Anyone think
this is a bad idea?
DavidF: Tony could you send this (your email) to i18n and can you put in a
sentence that comments on requirements to other WG, i.e. makes the statement
Tony: I can do that.
>6. Attachments (9.00 + 60)
>-- Placeholder for pending items
> o Update on Copyright and IP statements
>-- Document summary, 'stable'
> o Proposed Infoset Addendum to SOAP Messages with Attachments, private doc,
> 1 April 2003,
>http://www.gotdotnet.com/team/jeffsch/paswa/paswa61.html [starting point doc
>for WG's Attachment work]
> o Attachment Feature, WD, 24 Sept 2002,
>http://www.w3.org/TR/2002/WD-soap12-af-20020924/. The WD decided at its
>December 2003 f2f to park this document (or the Ed Copy) when MTOM etc goes
>to Last Call.
> o Attachment Feature, Ed Copy, 24 Sept 2002,
>http://www.w3.org/2000/xp/Group/2/07/SOAP-AF/aftf-soap-af.html [how is this
>different from the WD?] The WD decided at its December 2003 f2f to park this
>document (or the Ed Copy) when MTOM etc goes to Last Call.
>-- Document summary, 'active'
> o SOAP Optimized Serialization Use Cases and Requirements, WD,
>12 November 2003, http://www.w3.org/TR/soap12-os-ucr/
> o SOAP Message Transmission Optimization Mechanism (MTOM), WD,
>9 February 2004, http://www.w3.org/TR/2004/WD-soap12-mtom-20040209/
> o SOAP Message Transmission Optimization Mechanism (MTOM), Ed Copy,
>2004/01/27 09:40:03 $ 27 January 2004,
> o XML-binary Optimization Protocol (XOP), WD, 9 February 2004,
> o XML-binary Optimization Protocol (XOP), Ed Copy,
>2004/01/27 09:40:21 $ 27 January 2004,
>-- Action items:
>Compile technical reasons not to use XInclude
>DONE, see http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2004Feb/0039.html
>Is this draft correct and complete? Is there a reason not to send it?
DavidF: sent out a draft response to core and got couple of comments
(Noah+DavidO) about reordering and moving the XQuery DM item lower in the
list, some rephrasing, adding security as an issue (in the list of issues
that we discussed to come to the conclusion). DavidO had a comment about
areas where xinclude is large in scope than what we need (Xpointer etc).
I propose to roll Noah's and DavidO's text into my original draft and send
it to XML Core WG.
MarkN: i agree with the conclusion. Is there an point in telling the core folks
that in the future they may want to consider the issues and the process that
we went thru -- no point in each group reinventing the wheel. If you took
into account these issue then more groups can use this. I would like to make
our comment more positive.
Noah: i think we need to be polite and concilatory given that this is a very
sensitive issue. I would want to be careful about saying what we would be
willing to do if core indeed addressed our issues -- as to whether we would
use their spec.
MarkN: i agree. My intent is not to offer them a carrot but to be more
DavidF: i would like to send this asap. I will roll in Noah's and DavidO's
comments and craft a couple of sentences that are positive but mindful to not
mislead the core group that we would not necessarily use their spec if they
changed it. I will send an email to the WG and wait for a couple of days to
>Generate consolidated UC & REqs doc, using f/back from telcon etc.
>DONE, see http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2004Feb/0047.html
>Mike to remind us of next steps.
DavidF: is there anything that you need from the WG at this time?
Mike: the only point that Jacek pointed out that we should have two separate
issues instead of just one issues #459
DavidF: yves could you split 459 for us please.
>-- Issue discussion.
>=ISSUES REQUIRING A FIRST STEP=
>o 460, http://www.w3.org/2000/xp/Group/xmlp-issues.html#x460, Let the
>implementation decide to create a part?
Gudge: I think Erik is right, but that was our intent.
Noah: I agree with Gudge. The draft should say -- base64 are only optimization
candidates. But I think there are people who are confused about the property
that has a list of candidates for optimization. People are asking me --
What if I have an existing data model and it has a subtype of base64? We expect
you to take that DM and create a new one -- we don't know about subtypes. We
are using the type name to say that -- you *may* optimize. What we should have
said is what we said before -- you must supply a property called
optimization candidate or we allow types which implementations know to be
subtypes of base64.
DavidF: at min we need to tighten-up the text to indicate the MAY nature of the
MarkN: since we are on the topic, i have talked to customers and they are
confused about the choice of the data model.
Noah: as one who believes that architecturally this is the right thing to do,
I agree with the comment.
DavidF: how do we fix this? assuming that the DM is going to stay there, can we
fix this by working on the text.
Noah: the non-contraversial one is to fix the text, the other one is to
reconsider the DM and reconsider the two deeper layers.
DavidF: 1) reconsider the DM 2) properties is another option,
3) non-controversial to say MAY nature of optimization. We could do #3 and
look at whether we need to fix the spec in a more fundamental way. We want
to handle this before LC.
Gudge: we can address Erik's three issue 460-462 by modifying the draft we
have. We are going to get feedback about this in LC stage, if people don't get
what we are saying they will tell us.
Gudge: that said, i would like to get rid of the DM.
DavidF: for the moment we should have somebody to propose new text to stress the
DavidF: issue # 460 can we have a volunteer to generate text?
Gudge volunteers to do it by friday
Gudge: process question: if we go to LC with DM but get a lot of feedback about
the DM and we change the presentation but not the content do we have to go
to LC again or can we proceed to CR?
DavidF: if we only change the presentation we would not have to go back to WD
MarkN: even if we take the DM out?
DavidF: in that case we may have to go back to LC
Noah: this is a grey area. I think if we want to change our mind then I would
like to do it earlier than later. I am relunctant to do this after LC. My vote
would be to put a WD out and get feedback. OR if we are going to do it then
lets make the decision and go ahead on it. I have gotten feedback from a few
people that people are confused.
DavidF: issue #461?
Gudge: my take on this is that type is in the eye of the beholder. The fact
that it is subtype of base64 then for XOP it is base64
Noah: another way to resolve this is to go back to the properties. We would
write -- you're confused becase you have a DM, unfortunately we dont know about
type hierarchy, you can rename the types as base64, this is all abstraction,
you can build this in your APIs. but it is confusing to people. OR we can say
that you build a list of optimization candidate.
Anish: from an implementation perspective there is no difference.
MarkN: there are three different approaches, it would be useful to have a
small write up on each approach and then decide. The write up would
characterize how it is presented.
DavidF: so the writeups would describe how we would describe.
Noah: we have said the difference in the exposition. I don't want to rewrite
the spec three times. The crux of this is how do you (the sender) supply
the data, types and what can be optimized and how things look on the wire.
The right thing to do is not to write a paragraph about this, but to write a
slice of the spec what you supply to xop and here is a root and non-root
DavidF: do we know what parts of the specs would be changed?
Noah: i think so, there are the ones what we had before the DM.
DavidF: would this work for you Mark?
DavidF: does this resolve all three issues? Would it help to have three para?
DavidF: let us do that then. Who is going to write these para?
Noah: I can do the "middle" one
Mark: I can do the "infoset extreme"
Gudge: i am already on the hook for 460, I can do the "simple change"
DavidF: this is text that we think will resolve 460-462. Deadline is a week
>o 461, http://www.w3.org/2000/xp/Group/xmlp-issues.html#x461, Restricted
>subtypes of base64Binary
>o 462, http://www.w3.org/2000/xp/Group/xmlp-issues.html#x462, Whitespace in
>=ISSUES READY FOR IMMEDIATE RESOLUTION=
>o 451, http://www.w3.org/2000/xp/Group/xmlp-issues.html#x451, referencing
>mechanism via 'Content-Type' and 'http' URI. Prposal to close this resolution
>by noting our decision to use CID, see
DavidF: we have a proposal. Do we agree?
No objection to closing 451 with the proposal.
Issue 451 is closed.
Gudge to send closing comments.
>o 450, http://www.w3.org/2000/xp/Group/xmlp-issues.html#x450, Referenced
>parts MUST include the 'Content-Transfer-Encoding' field and should include
>the 'Content-Length' field. Discussion started at
>This issue resolved in principle at 12/2003 f2f, see summary at
>It is proposed to close this issue without taking any action, per the
>sentiment expressed in
No objection to closing 450 without taking any action.
Issue 450 is closed.
MarkN to send closing comments.
>o 457, http://www.w3.org/2000/xp/Group/xmlp-issues.html#x457. Extension
>required for the Representation header.
>Send a proposal for issue 457 by EOW
>DONE, see http://lists.w3.org/Archives/Public/xml-dist-app/2004Feb/0018.html
>Several WG members have expressed concern that the extension may be out of
>scope. We will consider a proposal but unless it is agreed to be
>straightforward, we will consider resolving the issue without taking any
>action because it is out of scope.
DavidF: i have the impression that this was not a slam-dunk. Some folks had a
concern that this is complex.
Jacek: i had some comments but not substaintial. I think the proposal is pretty
good, some minor things about syntax.
Mark: i have some thoughts about this which I need to sit down and write. Don't
have big issue with the proposal. Will send out comment end of week.
Yves: the comment that Jacek sent would require some time, my goal was to make
Gudge: do we have a requirement to specify this?
DavidF: no, but there are lot of people who think that this is a good thing to
do if it is simple.
DavidF: we will wait for Mark to send his comments.
ACTION: DavidF to roll DaveO's and Noah's comments in the XML Core comment on
XInclude, also adding a more positive ending (today) 
ACTION: DavidF to send the comment (depending on the feedback) by the end of the
ACTION: Yves to split issue 459 into two issues for the separate requirements 
ACTION: Noah (property), MNot (datamodel) and Gudge (surface?) to propose the
three different expositions of the architecture (by the middle of the next week) 
ACTION: Gudge to send closing text on 451 
ACTION: MNot to send closing text on issue 450 to SVG and xmlp-comments