DRAFT XMLP WG F2F minutes, 1-2 March 2004
Attendance
Present
BEA Systems, Mark Nottingham
BEA Systems, David Orchard
Canon, Jean-Jacques Moreau
Canon, Herve Ruellan
IBM, John Ibbotson
IBM, Noah Mendelsohn
IBM, David Fallside
Microsoft Corporation, Martin Gudgin
Nokia, Michael Mahan
Oracle, Anish Karmarkar
SAP AG, Gerd Hoelzing
Sun Microsystems, Tony Graham
Systinet, Jacek Kopecky
W3C, Yves Lafon
Excused
Microsoft Corporation, Jeff Schlimmer
Oracle, Jeff Mischkinsky
SAP AG, Volker Wiechers
Sun Microsystems, Marc Hadley
Systinet, Miroslav Simek
Absent
DaimlerChrysler R. & Tech, Mario Jeckle
DaimlerChrysler R. & Tech, Andreas Riegg
IONA Technologies, Mike Greenberg
IONA Technologies, Seumas Soltysik
SeeBeyond, Pete Wenzel
Scribe is Gerd Hoelzing
1.Agenda review by DavidF.
Action Items as listed in the agenda.
Local Arrangements: WG dinner in the evening - list of participants to be collected.
Meeting with Core WG
Goal for meeting with Core WG today is to discuss usage of xinclude and come to
some common understanding what XMLP needs , what Core provides and what is
missing to solve XMLP's requirements. Meeting is scheduled after lunch , meeting
is expected to last until 3pm.
Overview on Tuesday schedule, disposal of issues/resolutions and finishing of
outstanding issues.
Meeting with WSD WG
Lunch session scheduled with WSD WG on Wednesday to discuss MTOM/XOM technical details
to reach some level of agreement - there are some dependencies - see agenda.
Comment from HugoH: All WSD specs go for Last Call in May 2004.
DavidF: Notes XMLP's dependency on WSD WG and the MIME task force, see agenda
2.Minutes from Feb 18 approved with no objection
3.Review on action items, status covered on IRC
Status Reports:
- Media type registration: Still open, MarkN
- XMLP/WSD task force, Anish, nothing new
4.Existing issues:
457 postponed for Yves in the afternoon
453 Still under investigation by MarcH. MarkN questions what are the real
benefits of 'multipart/multiplexed' versus 'multipart/related'.
Some discussion on interoperability issues by allowing different packaging
schemes and how to indicate(by media type,etc.). To summarize, XOP does not
exclude the use of RFC 3391 but MTOM defines the restrictions which MUST
be applied for usage.
Issue closed with resolution incorporating this summary, and without objection.
455 Proposal in progress/Noah
Some discussion on use cases of roles/actions (for example if the role is next
and forwarding than you have to resinsert).
WG agreed that some rework on the spec seems required to clarify exactly
what the roles (for example 'next') cover and what they do not.
Conclusion: Representation header goes to a separate document and the proposal
will be based on Jacek's 'None' approach.
Action item to Anish for a draft on representation header (for tomorrow).
460 open
461 As 460
462 Proposal at - see agenda. Resolution is that the issue does not exist. Response
will be sent out bye mail (Jacek). Further, more explanatory text (from Jacek)
will be added to the Introduction section in XOP (editorial).
Issue closed without objection.
458 Impact of XML 1.1
Summary of Poll: majority depends on XML 1.0 and the minority is evaluating
XML 1.1 impact.
Comment from MarkH: It was *never* possible to serialize an Infoset and to
reproduce the Infoset(after transmission) correctly.
Suggestion from chair: Set up a TF to evaluate the dependencies of SOAP 1.2 on
XML 1.0 and the impact of XML 1.1 on SOAP 1.2 and later.
TF MEMBERS: MarkN,JohnI,Noah,Herve,Anish,Tony (all but not Jacek and
Gudge)
=== IRC log from morning session ===
<davidF> ACTION: gudge to respond to SVG and xmlp-comments re. issue 453
<noah> ACTION: Noah to send email openning issue on updating SOAP 1.2 HTTP binding
to reflect MTOM. (already done)
<mnot> ACTION: assure that the means of identifying XOP packages, including the
underlying packaging mechanism, are accounted for in the media type TBDs in the spec(s).
Discussion occurred in relation to issue 453.
<JacekK> ACTION 4= Anish to generate the first draft of the Representation document (by 3/10)
<JacekK> ACTION: Anish to concretize proposed resolution for 455 by 3/2
<davidF> http://lists.w3.org/Archives/Public/xml-dist-app/2004Feb/0031.html
<JacekK> ACTION: JacekK to send closing email to 462 stating what I proposed and
that it will be added to the XOP introduction
<JacekK> ACTION 7= Editors to tweak XOP introduction (paras 2 and 3) to incorporate
resolution to 462 (http://lists.w3.org/Archives/Public/xml-dist-app/2004Feb/0031.html)
<JacekK> should it be the official W3C position that every XML-related spec of W3C
must support any XML?
<JacekK> ACTION 8= MNot to raise the issue on clarification about infosets transported
by SOAP 1.2 bindings being limited to those serializable
<JacekK> ACTION: Chair to set up a time-limited XML 1.1 task force (regarding
issues 458 and the new binding infoset issue)
Scribe is John Ibbotson
<John> objective -come to a common understanding of each others' points of view
<John> 5 points from JCowan (from WSD)
<John> 1: Multipart related mime allows multiple objects
<John> 2 content id and cid for xreferenceing
<John> 3 add base64 mode to XML nclude
<John> 4 OK to profile
<John> 5 Can use standard tools
<John> Net: XInclude usable if a base64 type is added
<John> Understand XMLP may want to profile
<John> willing to try and make it usable
<John> Arnaud: Know about selected processing of elements
<John> xml include already supports adding additional attributes for soap-specific use
<John> Noah: xml include proposals match our concerns
<John> need for base 64 support and need to control in soap binding
<John> need for a 1:1 representation in serialization
<John> some diversity between common use with XML Include from timing point of view
<John> Need to be able to send SOAP infoset that may include any content
<John> discussion on use of a generic vs include processing for specific xop features
<John> foreign attributes on XML Include elements ignored by generic processors
<Yves> http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2004Feb/0073.html
<John> #4 use of schema data model
<John> (from David F's email to XML core)
<John> Noah describes reasons for use of XML Query data model
<John> discussion clarifying base64 characters as representation of binary octets - misconception
<John> core: different to the way XML Include thinks of it
<John> Noah walks through a simple usecase for clarification
<Gudge> http://www.gotdotnet.com/team/mgudgin/pics/mjg.jpg
<John> "business card" use case including jpeg image
<John> Davidf: Also, from XMLP's point of view, optimization is a MAY, not a MUST
<John> Gudge explains "upside down" approach
<John> Noah: point #5 - Security
<John> Gudge: General problem - how do we lock down these issues within a SOAP environment
<John> Arnaud: What's difference with SOAP profiling XML (no DTDs etc) and profiling
XML Include ?
<John> David O: Concerns about scope and complexity of XML Include. The subset needed
by SOAP seems to involve very little reuse. Are we buying much ?
<John> DavidO: minimal reuse is a compelling fact
<John> Arnaud: Security point raised is "flaky". John Cowan (on phone) agrees
<John> Noah: I think it's a close call, personally could go either way. We
<John> got tremendous synergy with XML - but some security holes - large benefit,small hole
<John> reverse with XML Include
<John> Jonathon: Need to put this to bed, discuss/list benefits - otherwise list why not used
<John> Anish: No technical reasons not to use,timing issues. Can XML Include add
functionality by SOAP last call ?
<John> Jonathan: doesn't see timing problems
<John> Paul G: expects to go to CR by end of Month - with or without base64
<John> Use of xinclude or xbinc:include will not impact WSD WG
<John> Davidf: we should talk about benefits
<John> Jack: 2 benefits. 1. Quick impl of XOp can use Xinclude. 2. Merge XOP with
generic XInclude s/w
<John> 2. Get a XOP package and use generic XInclude software to do the includes
<John> Specification benefit: Some words needed to describe xop as to qualify/profile
XInclude. However, user needs to understand all of XInclude to understand the profile
<John> Implementation benefit
<John> John Cowan mentions a documentation benefit
<John> Daniel: (Core) Most of XMLP use of XInclude will preclude most of XInclude
spec - that is more dangerous than beneficial.
<John> Davidf: Xinclude has many facilities but ony talks about half of what XOP needs
(the receiver side). SOAP also needs sender side. Have to understand both parts: creation and
reconstruction
<John> Multipart and cid not points of difference
<John> Difference is whether to use xbinc: include or not
<John> Sentiments:
<John> JJM supports Mike on ease of implementation of XOP on embedded devices
<John> Mark N: it is a timing issue only
<John> Noah: XOP separately seems simpler, but no strong preference
<John> Anish: Biggest issue timing, technical too close to call
<John> Mike: XOP easier for embedding
<John> Tony: XOP simpler but conflict
<John> Herve: Both ways same size of spec - a XOP implementation is simpler
<John> Yves: Better to reuse in "spec world", but implementation simpler for XOP
<John> Hugo: ditto
<John> Arnaud: Still likes reuse of syntax if nothing else. But DavidO's comment
on reusing such a small amount - I can go either way
<John> Philippe: Not worth reusing
<John> Paul: Likes reuse, but since so little reuse, not worth it. Philippe said
"to heck with it" :-)
<John> Jonathan: Cost of managing cross references between multiple specs. Small
overlap, so don't use XInclude
<John> Richard:Still in favour of using XInclude
<John> Glen: Same as Philippe :-)
<John> DavidO: On personal level, likes reuse of XInclude. Binary scope of XOP
precludes use of wider scope of XInclude
<John> John Cowan (phone):Rebut use of only a small part of spec. Others use
small parts of the spec. Generalised reuse of tools and applications. Document reuse makes the case.
<John> JJM: Agree with Philippe
<John> John I: use XOP rather than reuse XInclude
<John> Jack: Same
<John> Gudge:ditto
<John> Norm: I am 51:49 in favour of XOP
<John> daniel: use XOP, it is more dangerous to use XInclude,
<John> Davidf: the concensus is not to reuse XInclude. I note that many people
started this session supporting reuse, but have changed their minds
<John> As chair of XMLP, we will continue to use XOP and not reuse XInclude
<John> We need to tell the world why we have done this, though not in a debate
format between the two WGs
<John> We'll set up a joint WG task force to produce a document to describe our decision
<John> XML Core is not a public WG, and so whether we make these minutes public is TBD
<John> DavidO: Friendly amendment - reopen should XMLP find they have to make use
of more XML Include functionality
<John> John Cowan (phone): request to add mapping xop/Xinclude to xop spec
<John> DavidF: objects to JohnC's request
<John> XML Core to discuss themselves
<John> Proposal: XMLP will move forward using xop. 1. If XMLP uses more of XInclude,
we will revisit the issue. 2: We will set up a joint WG taskforce to create a
publicity sheet/statement/FAQs describing our decision.
<John> Any objections ?
<John> No objections - the proposal passes.
<John> break 15:30
<davidF> ACTION: XMLP chair to co-ordinate XMLP/Core minutes and organise XOP/XINCLUDE FAQ TF
Scribe is John Ibbotson
(<jjm> http://www.ermitage-du-riou.fr/home/english/index.asp)
<John> issue 448:
<John> Jack's proposal http://lists.w3.org/Archives/Public/xml-dist-app/2004Feb/0032.html
<John> DavidO: good starting point
<JacekK> is there the same issue (as DaveO's validation of xop:include) in SOAP 1.2 Envelope?
<John> Proposal: To say include elements should not include any attributes or children
<John> Implementations are free to ignore any extension attributes or children
<John> DavidO wins group straw poll
<John> Can have additional attributes or child elements, but MUST ignore if unknown.
They MUST NOT change the semantics
<DaveO> elements and attributes are allowed and must not change semantics.
Any such unknown elements/attributes must be ignored.
<John> ... of XOP include processing
<John> They MUST be qualified and in a separate namespace
<DaveO> xop:Include has zero or more namespace qualified EIIs in its [children]
property whose [namespace name] is NOT xopnamespce
<DaveO> xop:Include has zero or more namespace qualified AIIs in its [attributes]
property whose [namespace name] is NOT xopnamespace\
<DaveO> Such EIIs and AIIs MUST NOT change the semantics of processing the xop:INclude element.
<DaveO> Unrecognise EIIs and AIIs MUST be ignored
<John> 4 statements above will be added to the existence of the href attribute -
this is the proposal for resolving the issue
<John> DavidO: resolves first part of issue 448
<DaveO> If roughly same are done for representation header, then issue closed.
<John> this completes proposal
<John> no objections - issue 448 closed
<JacekK> ACTION: DaveO to send closing email on issue 448 (to originator and xmlp
comments) describing the resolution
<JacekK> ACTION: Editors to implement the above resolution to 448
<John> Issue 452
<John> SVG will email responses to SOAP WG this evening
<John> postpone until Tues
<John> Issue 454
<davidF> http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2004Feb/0076.html
<John> Discussion of Gerd's email http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2004Feb/0076.html
<Gudge> ACTION: Editors to make change to Section 2 ( and possibly 2.1 ) to
clarify that any other packaging mechanisms must transport the infoset with full fidelity
<John> This is preamble to issue
<John> part 2 of Gerd's note
<John> clarify: content transfer encoding should have the value of binary in the mtom http binding
> s/should/MUST
<Gudge> All binary parts MUST have a Content-Transfer-Encoding header
<Gudge> s/All binary parts MUST have a Content-Transfer-Encoding header/
<Gudge> Each MIME part that is refered to by xop:Include/@href MUST have a CTE of binary
<John> Proposal for resolving 454
<davidF> .... to appear in MTOM HTTP binding
<John> no objections, issue 454 closed
<JacekK> ACTION: Gudge to send the closing email on issue 454
Scribe is Martin Gudgin
<scribe> Issue 455
<scribe> Anish summarises an e-mail he sent to Noah
<scribe> Noah: Concerned that 'none' role takes a header outside the SOAP processing model
<scribe> Noah: There is also an ordering issue in that the Representation header
will need to be processed before any header that contains a URI that references that Representation header
<scribe> Gudge: Feels very like multi-ref target
<scribe> Noah: Disagree, think multi-ref targets are just arbitrary XML, not specific QNames
so are not processed per the SOAP processing model
<scribe> Anish: Why not use 'ultimatereceiver'
<scribe> Anish: Intermediaries can look at the headers anyway
<scribe> Noah: Difference between looking at the header and processing the header in
whatever way it is supposed to be processed
<scribe> Jacek: Can view this two ways. The 'none' approach says the URI resolver
looks inside the message for Representations to use.
<scribe> jacek: Other view is that when it's processed is that it adds the representation
to the URI resolvers cache
<scribe> Noah: I thought we decided that 'next' with reinsertion was the way to do 'all'
<scribe> Gudge: I think 'next' with 'relay=true' just says the first node that understands
the header processes it ( and removes it )
<scribe> Gudge; Reinsertion is completely orthogonal
<scribe> Anish: If a representation header and header A that references it are targetted
and next and some role 'R' respectively, the lifetime of the two headers is different
<scribe> Noah: Think we are tuning for a marginal case
<scribe> Noah: Say that 'next' with 'relay=true' means to reinsert even if it's understood.
<scribe> Noah: My proposal is just to highlight that you can reinsert the Rep header
in the case where its targeted at a none 'next' role
<scribe> JJM: We could invent a role that says reinsert if you understand
<scribe> JJM: That would stop anyone from deleting the header
<scribe> JJM: Would also avoid extra string comparison
<scribe> Proposal: Define a new role, 'Anish', if relay='true' then even if you understand
the rep header you must reinsert it
<scribe> Noah: This is an ordinary header. If the role is 'Anish' and you process it reinsert it
<scribe> Noah: May want to note that setting relay='true' will help the header survive a
node that doesn't understand the Rep header
<scribe> Gudge; Anyone who doesn't understand Rep header will forward anyway because it
doesn't play that role.
<mnot> Special Purpose Arrangement for Representation Termination In Closed or Unrestricted Systems
<scribe> Proposal (again): Define a new role. Characteristics of this role are; 1. if you
process a Rep header targetted at this role, you MUST resinsert it.
<scribe> Anish: Another question, can you have two rep headers for same URI
<scribe> Noah: We should say that it's OK for two Representation headers in a message to
have the same URI and role
<scribe> Noah: I'd rather add a note saying that such headers would typically have
different media types
<scribe> s/media types/metadata
<noah> s/metadata/metadata such as media type/ :-)
<scribe> Proposal for resolving 455: Define a new role as above. Add the two statements
above concerning two representation headers and the note about metadata
<scribe> noah; we might also need to add an issue regarding ordering
<scribe> Noah: Add text stating that implementations might need to process Rep headers
before other headers that might deref URIs
<scribe> Proposal for resolving 455: Define a new role as above. Add the two statements
above concerning two representation headers and the note about metadata. Add text stating that
implementations might need to process Rep headers before other headers that might deref URIs
<scribe> Issue resolved with above resolution without objection
<JacekK> ACTION: JJM to write closing email for issue 455
<JacekK> ACTION: Editors of Representation header spec to incorporate the resolution to 455
<scribe> Issue 457
<scribe> See agenda for our previous discussion
<scribe> Yves: My proposal was to do something lightweight. Allow the recipient
of a Rep header to act as a cache, but not require a sender to know about such behaviour
<scribe> Yves proposal is at http://lists.w3.org/Archives/Public/xml-dist-app/2004Feb/0018.html
<scribe> mnot: Still needs some work, but moving Rep header to seperate spec has
removed any concerns I have
<scribe> Chair: Do we know what the complete modified proposal will be based on
the e-mail thread?
<davidF> http://lists.w3.org/Archives/Public/xml-dist-app/2004Feb/0018.html
<scribe> Proposal: Close 457 by adding Yves proposal to the Rep spec
<scribe> Adopted without objection
<JacekK> ACTION: Yves to send closing email on issue 457
<JacekK> ACTION: Editors of Representation header spec to incorporate the resolution to 457
<scribe> Break until 10:30
<scribe> Resume at 10:45
<scribe> Comments from SVG
<davidF> re 450, SVG's commnets http://lists.w3.org/Archives/Public/xml-dist-app/2004Mar/0005.html
<scribe> SVG would prefer we used Content-Length rather than MIME boundary
<scribe> mnot: Agree with Chris, but if we want Content-Length we should use a different
substrate rather than multipart/related
<JacekK> http://www.w3.org/mid/46340070.20040302093244@w3.org
<scribe> Above link is for SVG response to Issue 452
<scribe> mnot: I can imagine use cases where people want to send SVG over web services
<scribe> mnot: And we have a bit of a problem
<scribe> gudge: we can still transmit SVG, just can't optimize attributes
<scribe> noah: We've debated this. Do we have another proposal on the table?
<scribe> noah: We felt in San Francisco that this was too big a whole
<scribe> Jacek: We need not change our mind. We can give them an example of how to use
the Representation header.
<scribe> Noah: I'm guessing they want to optimize existing SVG serializations.
<scribe> mnot: Didn't we have a proposal for how to optimize attributes
<scribe> gudge: Don't want to support optimization of attributes
<scribe> mnot: It's not a good use case to design for
<scribe> chair: Is that the concensus of the group?
<scribe> chair: Any objection to closing 452 by saying we are not going to support
optimization of attributes
<scribe> no objection to above
<scribe> 452 is closed
<JacekK> ACTION: Jacek to write the closing email on issue 452 (declining to take any action)
<scribe> Issue 460, 461
<scribe> Last time we discussed this we decided to get 3 proposals
<scribe> Text for existing spec: http://lists.w3.org/Archives/Public/xml-dist-app/2004Mar/0000.html
<scribe> Properties: http://lists.w3.org/Archives/Public/xml-dist-app/2004Feb/0030.html
<scribe> Noah: Think the Text approach is workable. But what we've done is confusing
to people and is easily fixed.
<scribe> Noah: We've used dm:type as a switch for whether a node is to be optimized
or not
<scribe> Noah: This proposal suggests we specify that you need a data model plus a
list of nodes the you would like to see optimized
<scribe> noah: walks through his proposal e-mail
<scribe> Infoset: http://lists.w3.org/Archives/Public/xml-dist-app/2004Mar/0003.html
<scribe> mnot: walks through is rewrite of the spec
<scribe> mnot: moved all terminology to infoset from dm
<scribe> mnot: removed appendices WRT mapping between infoset/dm
<scribe> mnot: We've really looking at a stylistic difference
<scribe> noah: agree that this is a stylistic issue
<scribe> Straw poll, preference for the three different approaches:
<scribe> mnot: prefer the Infoset because it's what SOAP 1.2 is based on. seriously
considering a formal objection if we continue with data model
<scribe> noah: I pushed us to consider the data model. On purely architectural grounds
the data model is closest to what we want. W3C problem that we have multiple data models,
there should be only one.
<scribe> noah: maybe we should comment to query about infoset extension rather than
data model
<scribe> noah: minor preference for dm, but will concur
<scribe> anish: i have a slight preference for the data model. Based on the discussion
we had during the DM task force. I think we should stick to the decision. I'd not lie in the
road if we decided to go back to Infoset
<scribe> Michael: Preference for infoset formulation. Arguments from Mark resonate and
my preference is pretty strong.
<scribe> Tony: Strong preference for infoset
<scribe> Gert: Can live with both but prefer infoset
<scribe> Herve: can live with both but have slight preference for infoset ( as an editor
it's easier ). Might be easier for the future to stick with infoset
<scribe> Yves: I like the data model approach but for us it's better to stick to the
infoset model.
<scribe> JJM: Abstain, I have not been involved in discussion.
<scribe> John: Slight preference for data model.
<scribe> Jacek: I'm with mnot. Prefer infoset, not quite so strong preference.
<scribe> Gudge: Strong preference for Infoset
<scribe> chair: We should send a note to Query on our concern over them defining a
new data model
<scribe> noah: could also 'piggyback' on comment from Schema WG
<scribe> Proposal: Rewrite the spec in terms of the Infoset ( adopt approach number 3 )
<scribe> noah: minor preference for using the list description rather than being silent
of what the candiates are for optimization
<scribe> mnot: list property feels SOAP specific, makes more sense in MTOM than XOP
<scribe> noah: Happy either way. Let's make markNs proposal status quo, but allow
reopening issue later
<scribe> Three pieces:
1. Remove DataModel from spec and use Infoset terminology.
2. Use the formulation in Mark's proposal for how to deal with optimization candidates.
3. Responding to Query
<Tony> http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0178.html
<scribe> ACTION: Noah to find out of XML Schema WG have communicated to XML Query WG
regarding extension of Infoset rather than new data model
<scribe> Three pieces: 1. Remove DataModel from spec and use Infoset terminology.
2. Use the formulation in Mark's proposal for how to deal with optimization candidates.
3. Responding to W3C community on problem with multiplicity of data models
<scribe> chair: any objection to closing 460 with above three pieces?
<scribe> no objection, 460 is closed
<JacekK> ACTION: Gudge to send closing email on issue 460
<scribe> issue 461
<scribe> moot with mnot proposal as it is lexically based rather than type based
<scribe> no objection to closing 461 with the above
<JacekK> ACTION: Gudge to send closing email on issue 461
<scribe> issue 449
<scribe> We should say that it's OK for two Representation headers in a message
to have the same URI and role and add a note saying that such headers would typically
have different metadata
<scribe> the above was discussed under issue 455
<scribe> and addresses 449
<scribe> 449 is so closed with no objection
<JacekK> ACTION: Anish to send closing email to issue 449
<scribe> davidF: only issues remaining are 458: XML 1.1, 443: media-type information
for binary data, discussing with WSDesc tomorrow
<scribe> issue 463
<scribe> Jacek: We can close this because it is straightforward, given we mandate the
cid: scheme, to generate unique identifiers for each part
<davidF> Jacek: We can close this because it is straightforward to generate unique
identifiers for each part (, given we mandate the cid: scheme,)
<scribe> no object to clsoing issue 463 with above proposal
<JacekK> ACTION: Tony to send closing email on issue 463 only to XMLP comments
<scribe> only issues remaining are 458: XML 1.1, 443: media-type information for
binary data, discussing with WSDesc tomorrw, 447: recoginizing XOP/MTOM in SOAP HTTP binding,
dependant on 458
<JacekK> ACTION: MNot to generate a proposal on issue 464
<scribe> break for lunch until 1pm
<scribe> will discuss SOAP 1.2 Rec issues after lunch
<davidF> rrsagent, what are the actions?
<RRSAgent> I see 25 open action items:
<RRSAgent> ACTION: gudge to respond to SVG and xmlp-comments re. issue 453 [1]
<RRSAgent> ACTION: Noah to send email openning issue on updating SOAP 1.2 HTTP
binding to reflect MTOM. (already done) [2]
<RRSAgent> ACTION: assure that the means of identifying XOP packages, including the
underlying packaging mechanism, are accounted for in the media type TBDs in the spec(s).
Discussion occurred in relation to issue 453. [3]
<RRSAgent> ACTION: Anish to generate the first draft of the Representation document (by 3/10) [4]
<RRSAgent> ACTION: Anish to concretize proposed resolution for 455 by 3/2 [5]
<RRSAgent> ACTION: JacekK to send closing email to 462 stating what I proposed and
that it will be added to the XOP introduction [6]
<RRSAgent> ACTION: Editors to tweak XOP introduction (paras 2 and 3) to incorporate
resolution to 462 (http://lists.w3.org/Archives/Public/xml-dist-app/2004Feb/0031.html) [7]
<RRSAgent> ACTION: MNot to raise the issue on clarification about infosets transported
by SOAP 1.2 bindings being limited to those serializable [8]
<RRSAgent> ACTION: Chair to set up a time-limited XML 1.1 task force (regarding issues
458 and the new binding infoset issue) [9]
<RRSAgent> ACTION: XMLP chair to co-ordinate XMLP/Core minutes and organise XOP/XINCLUDE
FAQ TF [10]
<RRSAgent> ACTION: DaveO to send closing email on issue 448 (to originator and xmlp comments)
describing the resolution [11]
<RRSAgent> ACTION: Editors to implement the above resolution to 448 [12]
<RRSAgent> ACTION: Editors to make change to Section 2 ( and possibly 2.1 ) to clarify that
any other packaging mechanisms must transport the infoset with full fidelity [13]
<RRSAgent> ACTION: Gudge to send the closing email on issue 454 [14]
<RRSAgent> ACTION: JJM to write closing email for issue 455 [15]
<RRSAgent> ACTION: Editors of Representation header spec to incorporate the resolution to 455 [16]
<RRSAgent> ACTION: Yves to send closing email on issue 457 [17]
<RRSAgent> ACTION: Editors of Representation header spec to incorporate the resolution to 457 [18]
<RRSAgent> ACTION: Jacek to write the closing email on issue 452 (declining to take any action) [19]
<RRSAgent> ACTION: Noah to find out of XML Schema WG have communicated to XML Query WG regarding
extension of Infoset rather than new data model [20]
<RRSAgent> ACTION: Gudge to send closing email on issue 460 [21]
<RRSAgent> ACTION: Gudge to send closing email on issue 461 [22]
<RRSAgent> ACTION: Anish to send closing email to issue 449 [23]
<RRSAgent> ACTION: Tony to send closing email on issue 463 only to XMLP comments [24]
<RRSAgent> ACTION: MNot to generate a proposal on issue 464 [25]
Scribe is Jacek Kopecky
<scribe> SOAP 1.2 Recommendation issues
<scribe> http://www.w3.org/2000/xp/Group/xmlp-rec-issues.html
<scribe> issue 9rec
<scribe> MNot: suggest changing "particular" to "given"
<scribe> jjm: change: "is understood" to "has been understood"
<scribe> other wording changes suggested
<scribe> proposal:
<davidF> "Table 3 summarizes the forwarding behavior of a SOAP node for a
<davidF> given header block. Each row contains a different combination of
<davidF> the value of the header block's role attribute information item,
<davidF> whether the SOAP node is acting in that role and whether the header
<davidF> block has been understood and processed and shows whether the header
block will be forwarded or removed."
<scribe> no objections to closing issue 9rec with that resolution
<scribe> ACTION: JJM to edit the errata incorporating resolution to 9rec
<scribe> ACTION 26= JJM to send the closing email on issue 9rec
<scribe> ACTION: Yves to edit the errata incorporating resolution to 9rec
<scribe> Gudge: where is the errata document?
<scribe> Yves: it is linked from the Rec document
<scribe> Issue 8rec
<scribe> ...going through the subissues
<scribe> the references to 8rec in the proposed resolution are in fact meant
to reference 7rec
<scribe> Chair: proposal to close 8rec with thus amended Anish's proposal
no objections
<scribe> 8rec is thus closed
<scribe> ACTION: Anish to send closing email on issue 8rec
<scribe> ACTION: Yves to edit the errata incorporating resolution to 8rec
<scribe> issues 10rec, 11rec
<scribe> herve: on some subissues MarcH and I suggested different resolutions,
mostly in cases of i.e. and e.g.
<scribe> davidF: we just want to pick one form of e.g. and i.e. and make the
spec consistent
<scribe> davidF: is it OK for the errata to contain a sentence in the form
of "all instances of i.e. and e.g. are changed so and so"?
<scribe> Yves: yes, and I'll start an ed's copy of the next edition
<scribe> davidF: any objection on spelling everything "e.g.," and "i.e.," with commas?
<scribe> no objections
<scribe> Gudge: why do we want to reformat a table in the errata?
<scribe> herve: the errata is a reminder for what changes are going to be in the
2nd edition
<scribe> davidF: any proposal to pivoting the table 4 in part 2?
<scribe> Yves: any other tables?
<scribe> davidF: we will minimize the occurrence of this problem by pivoting the
appropriate tables
<scribe> davidF: is this all for issues 10rec and 11rec?
<scribe> herve: there are other editorial subissues in these issues, issue 10rec
is against part 1, issue 11rec against part 2
<scribe> first subissue, proposal says no action
<scribe> davidF: do we need to add any clarification?
<scribe> herve: no, the reader was confused and I don't see how the spec could be
clarified, we will respond to this particular reader
<scribe> second subissue proposal:
<scribe> (on section 5.1.1)
<davidF> The scope of the encodingStyle attribute information item is its [owner
<davidF> element] and that element information item's descendants, excluding the
scope of any inner encodingStyle attribute information item.
<scribe> ednote in section 6:
<scribe> proposed resolution: chop the sentence starting with 'via'
<scribe> issue with "character information item children whose character code...":
<scribe> noah: let's split the sentences there
<scribe> proposal for all the appropriate places:
<davidF> The Detail element information item MAY have any number of character
information item children. The character code of each such character information item
MUST be amongst the white space characters as defined by XML 1.0 [XML 1.0].
<scribe> section 5.3.2, ednote around para 8:
<scribe> proposal: add the comma proposed by the commentator (contrary to Herve's proposal)
<scribe> proposed resolution with ", that is ...": change it to "; that is, ..."
<scribe> proposal: subissue on 'men-in-the-middle', accept commentator's proposal
as opposed to Herve's
<scribe> RESOLUTION: no objection to accepting the resolutions above (and Herve's
proposed resolutions where no change proposed at the f2f)
<scribe> ACTION: Herve to send the closing email for 10rec
<scribe> issue 11rec
<RRSAgent> See http://www.w3.org/2004/03/02-xmlprotocol-irc#T13-50-54
<scribe> first subissue: arraySize
<scribe> noah: arraySize is only a hint in SOAP Encoding, let's add a note about that
<scribe> davidF: do we need a clarification from the commentator on whether the first
subissue is any deeper
<scribe> davidF: option: divide issue 11rec into the first subissue and the rest
<scribe> RESOLUTION: no objection to opening a new Rec issue on first subissue of 11rec
<scribe> ACTION: Yves to make the first subissue of 11rec into another Rec issue
<scribe> break until 15:45
<scribe> further agenda: issue 11rec, schedule talk, second edition
<scribe> reconvening at 15:50
<scribe> continuing 11rec
<scribe> second subissue of 11rec is subsumed by our XML 1.1 issue
<scribe> the subissue about the use of "i.e." subsumed by previous decision as
part of 10rec
<scribe> subissue on width of table 4 subsumed by previous resolution to pivot
the tables
<scribe> proposal: at least the first use of Schema Recommendation should be
"W3C XML Schema Recommendation"
<scribe> chair: any objections to the modified proposal?
no objection
<scribe> RESOLUTION: issue 11rec closed with the proposed resolution as amended
in the minutes
<scribe> ACTION: MNot to send closing email on issue 11rec
<scribe> ACTION: Yves to edit the errata incorporating resolution to 11rec
<scribe> ACTION: DavidF to check 18rec for stuff we haven't dealt with yet as
part of other issues
<scribe> ACTION: Anish to propose a resolution to 19rec
<scribe> Topic: 2nd edition scheduling
<scribe> davidF: let's wait until we have resolutions to the issues at hand
<scribe> Jacek: the XML 1.1 issue should be amongst them
<scribe> davidF: let's open a new rec issue pointing to our XML 1.1 issue
<scribe> jjm: do we want to publish together with MTOM/XOP?
<scribe> davidF: no, I think 2nd edition should come after MTOM/XOP
<scribe> jjm: WSDL 2 SOAP binding could generate new rec issues
<scribe> davidF: reason for publishing sooner rather than later is the XML 1.1 area
<scribe> ACTION: Yves to put in a new Rec issue pointing to our XML 1.1 issue
<scribe> davidF: we'll wait with 2nd edition publication
<scribe> topic: Last Call for MTOM/XOP
<scribe> davidF presents the schedule outline
<item type="member-only">
<scribe> davidF: I propose to adjourn the meeting because we don't have anything
more on the agenda
<scribe> davidF: there is no telecon tomorrow
<scribe> Q: will we have another f2f?
<scribe> davidF: we don't seem to need one
<scribe> davidF: but we'll see
<scribe> meeting adjourned
<davidF> rrsagent, bye
<RRSAgent> I see 36 open action items:
<RRSAgent> ACTION: gudge to respond to SVG and xmlp-comments re. issue 453 [1]
<RRSAgent> ACTION: Noah to send email openning issue on updating SOAP 1.2 HTTP
binding to reflect MTOM. (already done) [2]
<RRSAgent> ACTION: assure that the means of identifying XOP packages, including
the underlying packaging mechanism, are accounted for in the media type TBDs in the spec(s).
Discussion occurred in relation to issue 453. [3]
<RRSAgent> ACTION: Anish to generate the first draft of the Representation document (by 3/10) [4]
<RRSAgent> ACTION: Anish to concretize proposed resolution for 455 by 3/2 [5]
<RRSAgent> ACTION: JacekK to send closing email to 462 stating what I proposed and
that it will be added to the XOP introduction [6]
<RRSAgent> ACTION: Editors to tweak XOP introduction (paras 2 and 3) to incorporate
resolution to 462 (http://lists.w3.org/Archives/Public/xml-dist-app/2004Feb/0031.html) [7]
<RRSAgent> ACTION: MNot to raise the issue on clarification about infosets transported
by SOAP 1.2 bindings being limited to those serializable [8]
<RRSAgent> ACTION: Chair to set up a time-limited XML 1.1 task force (regarding issues
458 and the new binding infoset issue) [9]
<RRSAgent> ACTION: XMLP chair to co-ordinate XMLP/Core minutes and organise XOP/XINCLUDE
FAQ TF [10]
<RRSAgent> ACTION: DaveO to send closing email on issue 448 (to originator and xmlp comments)
describing the resolution [11]
<RRSAgent> ACTION: Editors to implement the above resolution to 448 [12]
<RRSAgent> ACTION: Editors to make change to Section 2 ( and possibly 2.1 ) to clarify that
any other packaging mechanisms must transport the infoset with full fidelity [13]
<RRSAgent> ACTION: Gudge to send the closing email on issue 454 [14]
<RRSAgent> ACTION: JJM to write closing email for issue 455 [15]
<RRSAgent> ACTION: Editors of Representation header spec to incorporate the resolution to 455 [16]
<RRSAgent> ACTION: Yves to send closing email on issue 457 [17]
<RRSAgent> ACTION: Editors of Representation header spec to incorporate the resolution to 457 [18]
<RRSAgent> ACTION: Jacek to write the closing email on issue 452 (declining to take any action) [19]
<RRSAgent> ACTION: Noah to find out of XML Schema WG have communicated to XML Query WG regarding
extension of Infoset rather than new data model [20]
<RRSAgent> ACTION: Gudge to send closing email on issue 460 [21]
<RRSAgent> ACTION: Gudge to send closing email on issue 461 [22]
<RRSAgent> ACTION: Anish to send closing email to issue 449 [23]
<RRSAgent> ACTION: Tony to send closing email on issue 463 only to XMLP comments [24]
<RRSAgent> ACTION: MNot to generate a proposal on issue 464 [25]
<RRSAgent> ACTION: JJM to send the closing email on issue 9rec [26]
<RRSAgent> ACTION: Yves to edit the errata incorporating resolution to 9rec [27]
<RRSAgent> ACTION: Anish to send closing email on issue 8rec [28]
<RRSAgent> ACTION: Yves to edit the errata incorporating resolution to 8rec [29]
<RRSAgent> ACTION: Herve to send the closing email for 10rec [30]
<RRSAgent> ACTION: Yves to make the first subissue of 11rec into another Rec issue [31]
<RRSAgent> ACTION: MNot to send closing email on issue 11rec [32]
<RRSAgent> ACTION: Yves to edit the errata incorporating resolution to 11rec [33]
<RRSAgent> ACTION: DavidF to check 18rec for stuff we haven't dealt with yet as part of other issues [34]
<RRSAgent> ACTION: Anish to propose a resolution to 19rec [35]
<RRSAgent> ACTION: Yves to put in a new Rec issue pointing to our XML 1.1 issue [36]
Joint Meeting with XMLP and WSD WGs
Mark Nottingham is scribe
Abbreviated Agenda
1. Dependencies
2. Brainstorm for WSD
3. Task Force review
Jonathan: It would be good to review the specs XMLP are working on.
Gudge: [reviews XOP, MTOM and Representation Header specs]
Gudge: Interesting question from WSDL's standpoint is whether MTOM is
a new binding, or a feature added to the existing HTTP binding. This
isn't get decided in XMLP.
DavidF: What different would this make from a WSDL perspective?
Glen: A new URI. You either have to understand new markup or a new
binding URI.
Jonathan: It would be unfortunate if this were a new binding.
Glen: This isn't a new WSDL binding, just a new SOAP binding.
DavidF: This is a dependency.
Jonathan: The way this is modularized makes me ask whether we need to
do anything extra?
Gudge: just MTOM.
Noah: What's the relationship to media types? Should people be able to
say they're using SOAP with different SOAP bindings? Should people
using other bindings (e.g., MQ) be able to say they're using XOP?
Glen: Whether I'm using XOP could be common across a number of bindings.
Anish: Could this be a feature or property?
(several): yes.
Jonathan: Is it sufficient to just describe MTOM in the HTTP binding?
Glen: For now. Media type is perhaps a little bit too grounded to
describe what's happening.
Jonathan: Are we going to need to talk about XOP in the binding at all?
Jean-Jacques: WSDL2 has a new HTTP binding; Phillipe architected it so
that you can plug in XOP.
Glen: This is a WSDL/HTTP binding, not a SOAP binding. We're definately
going to do a SOAP binding; the question is whether we're doing a HTTP
one as well.
Jonathan: we'll need to determine if it's more than a flag, and there
are knobs to twist. I'd be interested in whether the XMLP group would
like us to do that.
Jacek: That would be good validation of the concept that XOP is
independent of SOAP.
Noah: You'll need something beyond description. Do you need a new HTTP
header? If you want to undertake describing the wire format, I'd
support that, but I don't know if the protocol group wants to go beyond
SOAP.
Jonathan: I don't hear anyone wanting to do this in production beyond
SOAP.
Gudge: We separated out XOP for other reasons.
??: WSDL doesn't need to invent yet more new things.
Hugo: Putting XOP in the HTTP binding may be easier, because of reuse.
Glen: not necessarily.
Jean-Jacques: that's what Phillipe had in mind.
Gudge: You need to look at the root media type. We're defining one for
SOAP/XOP. In a sense, XOP isn't useful on its own.
Noah: Media types are running out of gas. If they were a little
stronger, and there was XOP anywhere in the media type, you could use
that as a hook.
Glen: Yet another reason to move from mime to XML.
Anish: One thing that came up yesterday is that you could use XOP with
ZIP; that's another axis of variability.
Jonathan: It sounds like we've signed up for describing MTOM over a
HTTP binding.
(several): Yes.
Noah: I'd hope that you have a generic way to describe such extensions.
Glen: Yes; properties and features, same as SOAP.
Tom: But they're not exactly the same...
Glen: Essentially, they are.
Tom: We'd better write that down somewhere.
Jonathan: Now, what about the Representation header?
Anish: We separated it out because we realised it needed to be.
Jonathan: is this a knob on MTOM?
Gudge: no.
Jonathan: If I'm writing a description with these headers...
Gudge: How is it different from any other header?
Glen: How did you specify this? As a module, etc.
Gudge: of course not.
Glen: that's how you should specify soap headers.
Noah: We haven't written the spec yet.
Glen: The point is, if this is a module, and describes itself in
properties and features, it becomes very easy to describe in WSDL.
Jonathan: We'd need some glue to map the description to the presence of
the header.
Noah: At one level, this is a SOAP header. Perhaps properties and
features. For WSDL, there's a use case for SOAP where you have a URI in
your message that points to a Web resource. Do I get to type that
reference? It would be good to unify this.
Arthur: [different discussion with services vs. URIs]
Noah: Would be good to deal with the general case first; some
representations come with the message, some don't.
Tom: Don't know if we get to that level in WSDL.
Glen: we have a proposal for having pieces of data identified with
media types; we don't have the dimension of saying that it's a
reference.
Noah: I.e., do we want to characterise references?
Tom: It's application-specific; why would we want to do that?
Umit: We only have this for base64 embedded information, but not
references.
Noah: that's what our representation header does.
Anish: this is being discussed in the TF.
Noah: My point is that I want to type the representations returned by a
reference.
DavidF: Who decides what level of description is provided?
Jonathan: We do.
Tom: For wsdl 2, I'm concerned about feature creep.
Jonathan: We need an on/off switch for MTOM, and one for the header,
not sure if they're the same.
Glen: We've dropped the idea of a XOP switch
Noah: decision of whether to do it for SOAP or just SOAP/HTTP.
Tom: anything but SOAP/HTTP is out of scope.
Glen: Disagree; how do we box this up is the question. We don't have to
answer it now.
Tom: We don't have a typing mechanism for bindings.
Gudge: glen is asking if we should have something called "do xop"
Tom: Where would that show up?
Glen: This could be a feature with a URI.
Noah: If JMS does something that looks like MTOM, is it abstracted as
the same thing, or just two things that happen to use the same
infrastructure? I'm leaning towards the latter.
Glen: From the description POV, we're not talking about specific
implementations, but signals about what is in use. If I say MTOM is in
use on a binding, it tells the code "you should do that."
Noah: Sure, when two bindings share an abstraction, give it a common
name. But that doesn't mean that all features should be sharable.
Glen: And that's up to the guy writing the next binding to decide; if
we've called it out as an abstract thing, he can do that.
DavidF: We're arguing about the granularity of description; how many
switches? There's another issue: what do you (wsd) need from us (xmlp)?
What's the timeframe?
Jonathan: I'm not worried about the timeframe, because of lack of
issues or complexity. I may be wrong, but that's my current view.
DavidF: anybody else?
Gudge: we need to nail down the media type issue. That won't take long.
Glen: I would request that the XMLP group write the spec for the
representation header using the SOAP 1.2 extensibility model.
Gudge: object very strongly.
(several): what grounds?
Gudge: It's not a realistic model.
Jonathan: Let's not get into this now. Any other questions? I know that
we have to decide whether the media type is an extensibility point.
DavidF: If you wait until the end of next week, we'll have a first
draft of the representation header spec. We'll get the other versions
back up to speed even sooner.
Jonathan: We'll keep you informed.
Noah: We had a discussion of the Representation header; there's an open
issue of where we're going with Web representations in general. You may
want to keep an eye on us and step in if you think we're causing
trouble.
DavidF: Where is the media type task force?
Jonathan: Umit and Anish has put together a proposal. It hasn't got
thorough review yet; not much evolution.
Mark: New draft?
Umit: We haven't made any significant changes.
Anish: One open issue: Do we want to represent the media type or the
content type?
Umit: We have a presentation; should we do that?
DavidF: We have ten minutes.
Jonathan: I would like to talk briefly about SOAP 1.1.
Umit: The problem we were trying to solve has two components; 1) look
at it for just base64 types in schema, to indicate what the media type
of that base64 content is. 2) to declare the value of ranges for that
type; e.g., image/*.
Umit: Proposal is that you have an attribute for the instance, and one
capable of ranges for schema.
Gudge: Why not just subtype the attribute on the instance? Then you
just need it in one place. E.g., restrict the base type, rather than
have two different attributes.
Anish: But then you wouldn't have a standard attribute name.
Gudge: Why not? You're just doing restriction on the value.
Anish: If we have a standard attribute in a standard name-space, it's
better.
Gudge: Thinking about it, it wouldn't work for attributes because of
the way substitution groups work.
Jonathan: In our latest charter revision, we have a binding for SOAP
1.1. We tend to think it should be minimal.
Tom: reasoning is that we'd like people to have a transition path.
Jonathan: Our question: is that adequate? Do we need to think about XOP
for SOAP 1.1?
Anish: Is the WSDL group only thinking about SOAP 1.1, or also SOAP
with attachments?
DavidO: I don't think that was included in the charter.
Anish: WS-I is very close to finalising the attachments profile. I'd
expect that there should be a migration path.
Jonathan: We'll have to see. We wanted to make sure that SOAP 1.1 isn't
too attractive.
Hugo: As background, the reason why we're doing SOAP 1.1 binding is
because there are people using WSDL 1.1 to describe their SOAP 1.1
service; they want a drop-in replacement.
DavidO: We pushed for the addition of SOAP 1.1 to the charter; people
pushed back before that it wasn't there, so we asked for it. I'd expect
the same kind of push-back for SOAP with Attachments.
Noah: The new thing that comes up is the runtime negotiation that
support both SOAP 1.1 and SOAP 1.2. The question is can support all of
the reasonable combinations?
Glen: Yes, except for the SOAP 1.1 binding in conjunction with Upgrade,
because it isn't required. If they do both, they should though.
Noah: I don't want to have to use different endpoints.
Glen: That shouldn't be a problem.
Anish: Isn't that independent of WSDL?
Noah: WSDL could screw it up.
Glen: We don't do that.
Anish: The reason that I bring that up is that clients look at the WSDL
and decide.
Tom: From a WSDL point of view, you don't care, because you get the
endpoint out of WSDL as well.
Jean-Jacque: So we're not going to do MTOM in SOAP 1.1?
Jonathan: No. We do need to check our charter for SOAP With
Attachments. We'll expect a notification from you when you have your
drafts ready. We're not going to do anything with bindings in the next
few days.
Glen: Also, we should discuss the SOAP 1.2 encoding data model.
Jacek: I have proposed a SOAP data model schema language that would
make it possible to describe SOAP data models in WSDL. We'd like
feedback from XMLP, possible co-operation.
DavidF: Send an e-mail, we'll put it on next week's agenda.
Jonathan: We're just beginning discussion as well.
DavidF: We're at time.