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)

Present 13/11
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?
DavidF: no

>3. Approval of Feb 4 and 11 telcon minutes, 
>http://www.w3.org/2000/xp/Group/4/02/04-minutes.html and 
>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
>Remove R26
>PENDING until online copy is updated
>2004/02/04: DavidF
>Draft an email to SVG regarding resolution of 452
>PENDING response from SVG, see
> http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2004Feb/0035.html
>2004/02/04: MarcH
>Research on issue 453 (multipart/multiplexed (rfc3391))
>2004/02/11: Herve
>Update XOP spec to say that xop:Include cannot have any children per 
>2004/02/11: Herve
>Incorporate Gudge's security section text
>2004/02/11: Noah
>Send an email to xmlp-comments and editors to close issue 444
>DONE, http://lists.w3.org/Archives/Public/xmlp-comments/2004Feb/0007.html
>2004/02/11: Gudge
>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 
  the loop.
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 
  the plenary
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
>2004/02/11: DavidF
>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
>2004/02/11: Tony
>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
        more strongly.
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:
>2004/01/28: DavidF
>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
        get responses.

>2004/02/04: MikeM
>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.
>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
  optimization text
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
  optional nature.
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?
MarkN: yes.
DavidF: does this resolve all three issues? Would it help to have three para?
Anish: yes
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 
  from today.

>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 
>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.
>2004/02/11: Yves
>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
  it simple.
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.

Meeting adjourned.

ACTION: DavidF to roll DaveO's and Noah's comments in the XML Core comment on
XInclude, also adding a more positive ending (today) [2]
ACTION: DavidF to send the comment (depending on the feedback) by the end of the
week [3]
ACTION: Yves to split issue 459 into two issues for the separate requirements [4]
ACTION: Noah (property), MNot (datamodel) and Gudge (surface?) to propose the
three different expositions of the architecture (by the middle of the next week) [7]
ACTION: Gudge to send closing text on 451 [8]
ACTION: MNot to send closing text on issue 450 to SVG and xmlp-comments [9]