XMLP WG Telcon Minutes, 25 Feb 2004

Based on IRC Log

1. Roll.
Present 13/10
BEA Systems, Mark Nottingham
Canon, Herve Ruellan
IBM, David Fallside
IBM, Noah Mendelsohn
IBM, John Ibbotson
Microsoft Corporation, Martin Gudgin
Nokia, Michael Mahan (scribe)
Oracle, Anish Karmarkar
SAP AG, Gerd Hoelzing
Sun Microsystems, Marc Hadley
Sun Microsystems, Tony Graham
Systinet, Jacek Kopecky
W3C, Yves Lafon

Excused
BEA Systems, David Orchard
Canon, Jean-Jacques Moreau
Microsoft Corporation, Jeff Schlimmer
Oracle, Jeff Mischkinsky
SAP AG, Volker Wiechers
Systinet, Miroslav Simek
IONA Technologies, Seumas Soltysik

Regrets
SeeBeyond, Pete Wenzel

Absent
DaimlerChrysler R. & Tech, Andreas Riegg
DaimlerChrysler R. & Tech, Mario Jeckle
IONA Technologies, Mike Greenberg

[scribe] 2. Approval of agenda
[scribe] XML Core issue item 5 is of special interest
[scribe] Issues: Goal is to get proposals for f2f
[scribe] Item 8 postponed

[scribe] Agenda Item 3: no modifications requested to minutes, no objections to their approval, approved

[scribe] Agenda Item 4: Action Items
[scribe] No changes to AIs
[scribe] Note DONE items
[scribe] Req&UC document has bad url
[scribe] The url will be changed by Yves
[scribe] David - the attachment feature shouldn't be part of the uri

[scribe] Agenda Item 5
[scribe] Issue: Core's request
[scribe] Core wants to enter into a dialog - to figure out whether XMLP can or can't use XInclude instead of XOP
[scribe] Otherwise likely Core will object
[scribe] Technical issues are not terrible
[scribe] However, the resulting XInclude mechanism would be munged and may not be worth the effort
[scribe] So we need to have this discussion with Core and sell job that XOP is preferred
[scribe] Mark: Do you really mean replacing XOP with XInclude
[scribe] Noah: No just xop:include
[scribe] David: concur with the clarification
[scribe] David: we should spend couple hours with Core in our f2f at Cannes
[scribe] David: then after we make the decision regarding this issue - sooner rather than later
[scribe] David: That is the proposal for the group - to meet with Core
[scribe] David: We introduce MTOM & XOP then Core proposes how we use XInclude
[scribe] David: Then we discuss about requirements coverage and whether XInclude covers them
[scribe] David: Core is interested in meeting Monday afternoon 
[scribe] David: Whether and how we do the meeting is open
[scribe] Jacek: Accept the meeting - Core should prepare with proposal
[scribe] Jacek: Otherwise the meeting would be unproductive
[scribe] Noah: The implication of using xInclude would be to end up with xop:include
[scribe] Noah: xop restrictions are tuned to the requirements
[scribe] Noah: Finding the balance between the tradeoffs should be articulated up-front
[scribe] Noah: <lists some of the features of xop that makes xop:include preferred solution>
[scribe] Noah: Note that use of XInclude will be tradeoff
[scribe] Group: concensus that meeting is the right choice
[scribe] David: OK we will have meeting
[scribe] David: How to conduct meeting - we will suggest that they come prepared with proposal
[scribe] David: Issue we bring: security, mult include problem, items on the draft email
[scribe] David: Is the list sufficently covered in the draft email
[scribe] Jacek: see above!
[scribe] David: OK - will contact Core and will schedule for Mon meeting, after lunch

[scribe] Next Item - media type registration
[scribe] Mark: Still waiting on xml 1.1

[scribe] Next item - xmlp/wsd tf
[scribe] David: contacted Jonathan, answer was oblique because WSD not focused on this issue

[scribe] Next item: F2F planning
[scribe] David: Wed lunch with WSD
[scribe] David: I have drafted an agenda - on new f2f agenda
[scribe] David: Main thrust of f2f is to resolve issues
[scribe] David: New issues will appear on the next f2f agenda
[scribe] David: no call-in # - but the meeting with Core will have one

[scribe] Agenda Item 6
[scribe] David: Lets see if we can get proposals for f2f

[scribe] David: Where are we with issue 454?
[scribe] Noah: proposed variability in encoding
[Noah] http://lists.w3.org/Archives/Public/xml-dist-app/2004Jan/
[scribe] Noah: tracing the messages was a challenge
[Noah] http://lists.w3.org/Archives/Public/xml-dist-app/2004Jan/0028.html
[scribe] Noah: there were 2 different proposals 
[scribe] Noah: one proposal orginated from Mark, one from Anish (he believes)
[scribe] Noah: if 7bit clean, there is possibility to munge with whitespace
[scribe] Noah: was an Amy comment
[scribe] Anish: The Amy email discussed 7bit definition regarding ws rather than what intermediaries can do with it
[scribe] Noah: reads Amy's email
[scribe] Noah: are there still proponents for both proposals?
[scribe] David: Does Mark still support one of the proposals
[Gudge] how does Content-Transfer-Encoding relate to 454?
[scribe] Mark: we can just close issue - as long as in certain circumstances there is variability
[scribe] Anish: what if the message goes over transports that aren't 8bit clean
[scribe] Anish: at infoset level, c-t-e may do certain things, but it is still mapped to the infoset at receiver
[scribe] David: hence let MIME take care of it and close issue
[scribe] Noah: but in MTOM/HTTP we were to lock this down
[scribe] Noah: would like to minimize variability at the http binding
[scribe] Noah: puts forth proposal - that removes variability
[scribe] Noah: rationale - IOP
[scribe] Gudge: given the reason we do mtom (to reduce bloat) - why would we use encoding to put bloat back in?
[scribe] Gudge: 7bit clean data is outside the 80/20
[Gudge] 7-bit can't go in XML, because zero is not legal
[scribe] Noah: Anish is saying this happens (7 bit clean)
[Gudge] amongst other characters
[scribe] Jacek: for 7bit clean data - why isn't this in the infoset?
[scribe] Gudge: cant do it. Zero is not 7bit clean
[scribe] Anish: What do we gain with this restriction?
[JacekK] Gudge: can't do it. Zero is 7-bit clean but illegal in XML
[Gudge] s/Zero is not 7bit clean/Zero is 7bit clean
[scribe] David: what is proposal for constraint in http binding?
[scribe] Jacek: don't see value of supporting 7bit other than binary type
[scribe] David: need someone write this up as a proposal
[scribe] david: in section * of xop the dm must be transferred with fidelity
[scribe] David: in http binding the appropriate header has the value binary
[JacekK] ACTION 1=Gerd (with help from Gudge) to write up text for resolving issue 454 (data model transfer fidelity; locking to binary in HTTP) by 2004/2/27

[scribe] David: Issue 448
[scribe] Jacek: 2 sets of extensibility
[scribe] Jacek: scope that is
[scribe] Jacek: Soap header ,  XOP include
[scribe] Noah: extending xop:include adding new attributes just as long as it doesn't affect processing
[scribe] Noah: can't change the interpretation
[scribe] Gudge: no need for extensibility in xop
[scribe] agreement happens
[scribe] Gudge: Rationale appear the same as Noah's
[scribe] Jacek: may have to revisit after meeting Core
[scribe] David: can Jacek write up a proposal
[scribe] Jacek: OK - no extensibility in xop element
[scribe] Jacek: also mention the ext in the rep header
[JacekK] ACTION: JacekK to write up a proposal on issue 448 forbidding extensibility of xop:include and saying Representation is extensible enough by 2004/2/27
[scribe] David: the xop non-extension should be handled in the schema
[scribe] Gudge: Yes, but maybe not in the spec yet
[scribe] Herve: the spec does reflect this now
[scribe] Noah: should we clarify that the schema is normative? Agreement all around...
[Gudge] ACTION: Editors to ensure that spec notes that schema is normative

[scribe] Issue 455
[scribe] Jacek: Header is good candidate for role and not reinsert
[scribe] Jacek: Header without role can be processed at any node in message path
[scribe] Mark: this would be for next and relay attrs
[scribe] Jacek: relay only effective if dont understand
[scribe] Jacek: Otherwise role is effective
[scribe] Mark: none semantics do not match
[scribe] Jacek: disgrees - this is what none is meant to be
[scribe] Noah: either way - this is spec for a soap header
[scribe] Noah: if targeted to role, the spec rules work
[scribe] Noah, if targeted to none, semantics are unclear
[scribe] Noah: in absence of any other header processing to override, and targeted to next, then reinsert
[scribe] David: Can Noah write it up - augment with Marc
[JacekK] ACTION: MarcH to write up a proposal for issue 455 according to the minutes
[scribe] David: Action now to Marc

[scribe] Issue 458
[scribe] Gudge: thought this is against soap 1.2
[scribe] Noah: MTOM as well
[Yves] in issue list, the scope is mtom/xop + REC
[scribe] Noah: MTOM is use of base64 which is control characters clear 
[scribe] Noah: so the issue is geared more for soap 1.2
[scribe] David: Lets reslove this now for soap1.2 and then work down to mtom
[scribe] Noah: first, should we remove 1.0 from spec?
[scribe] Jacek: strong preference for allowing 1.1 to be used for soap 1.2 in http binding
[scribe] Gudge: counters that strong preference
[scribe] Mark: strong preference against - due to toolkits will not be compatible
[scribe] David: we will have to revisit this issue at f2f

[Zakim] WS_XMLP()11:30AM has ended

[RRSAgent] ACTION: Gerd (with help from Gudge) to write up text for resolving issue 454 (data model transfer fidelity; locking to binary in HTTP) by 2004/2/27 [1]
[RRSAgent] ACTION: JacekK to write up a proposal on issue 448 forbidding extensibility of xop:include and saying Representation is extensible enough by 2004/2/27 [2]
[RRSAgent] ACTION: Editors to ensure that spec notes that schema is normative [3]
[RRSAgent] ACTION: MarcH to write up a proposal for issue 455 according to the minutes [5]