W3C XML Protocol Working Group teleconference, 28 May 2003

Based on IRC log at http://www.w3.org/2003/05/28-xmlprotocol-irc.html

1. Roll

Present 13/9 Excused Regrets Absent

2. Agenda review



	

3. Approval of minutes

 have a couple of corrections: Herve's name and "has NO objections"
 no other corrections
 no objections, minutes approved as modified


        

4. Action items review



        

5. Status reports

 Planning next f2f meeting
 DF: we will first start putting together a page about the f2f (with hotels etc.)

 Creation of Q&A on SOAP 1.2 in WSDL 1.1
 DF: Glen thought the WSD WG should look at the SOAPBuilders' binding
 DF: Jonathan Marsh sees WSD WG as resource constrained already but will bring this up
 DF: we already have one volunteer, Anish
 anish: yes, I'm still willing to do this
 Tony Graham volunteers as well

 Registration of the media type
 MarkN: no progress yet


        

6. PR Issues

 428: Content-free header?
 DF: we have a new piece of text to be added
 DF: W3C staff advised that if no implementation has to be changed, we can safely add this text
 DF: so we polled the implementors
 DF: we heard back from 5 implementors, no changes to implementations necessary
 Gudge: Glen (apache) also replied saying no changes necessary
[jeffsch] http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2003May/0082.html
 DF: so only one implementor hasn't replied and we didn't expect him to reply anyway
 DF: I recommend we accept the added text as resolution to 428
 no objections to thus resolving issue 428 

 430: minor editorial - disagreement between examples and text
 no objection to handling this issue through email
 Nilo will propose text, a day or two later (if no objections) we'll proceed to fix it and close
issue


        

7. Attachments

 DF: IPR all co-authors responded, Canon statement evaluation pending
 DF: IBM, Microsoft responded OK, waiting for AT&T, SAP and TIBCO
 MarkJ: we're OK, will solve with DF in email
 DF: TIBCO hasn't participated, will probably soon leave the group
 JeffS volunteers to "poke them"
 DF: I will rather handle it myself

 Attachment requirements
 DF: we handled this in the document that's about to be posted
 DF: we still have requirements we haven't decided on
 DF: these are "larger issues"
 DF: we'll now talk about binding-mechanism and above-binding mechanism, then we'll come back to
the requirements
 no objections to this course

 DF: last week we started talking about PASWA as a binding mechanism and what it means
 DF: we have two descriptions now, let the authors speak about it a bit
 DF: we couldn't decide last week which direction we should take

 Herve (on binding mechanism): attachments are added in the message as base64 data
[davidF] (URL for description http://lists.w3.org/Archives/Public/xml-dist-app/2003May/0145.html)
 Herve: when asked to transmit the message, the binding will decode the base64 data and put it
into attachments, adding xbinc:Include elements and the DoInclude header
 Herve: on receiving side the process is reversed, the binding resolves the attachments making
them base64 data and removes the DoInclude header
 Herve: the implementations can actually skip the encoding/decoding steps, but in abstract it
is necessary that the steps are in the description
 MarkN: is this a binding or is this a binding feature?
[davidF] (URL for "above-binding" description
http://lists.w3.org/Archives/Public/xml-dist-app/2003May/0146.html that markN will present shortly)
 MarkN: if it is a binding, it's not too composable, a feature would be fine
 Noah: I don't think this is intended to be a binding
 Noah: this is only barely a binding feature, it's more like a "technique a binding may use",
it is not visible from the outside
 Noah: it should be clarified that in practice in implementations there could be some hints
on what might be attachmentized
 Noah: it actually doesn't matter if different bindings use different techniques
 Herve: the implementation can provide ways for applications to prevent the encoding/decoding
step
 MarkN: one could easily see this done as HTTP content-encoding
 MarkN: I would be concerned if we created a new binding that doesn't supercede the current
HTTP binding

 MarkN (on PASWA as a module):
 MarkN: we have to handle problems like order of processing
 MarkN: the processing of DoInclude must behave as though xbinc:Include elements were replaced
with the data
 MarkJ: it looks like this approach is more independent, it doesn't conflate bindings, they
don't have to be include-aware
 MarkN: for a general way, it's more appropriate to specify it as a module, yes
 MarkJ: there are still optimizations to be done in implementations
 MarkN: the approach as a module would still require some accomodation in the binding
implementations
 Noah: the bindings must be modified in any case
 Noah: the first proposal from Herve has the characteristic that the sender and receiver both
agree on the form of the message
 Noah: with the module approach, the situation is a bit more subtle
 Noah: we have to be careful about things like digsig and the relay rules
 Noah: so in multi-hop situation the relaying node would have to agree on the attachmentization
(scribe's words, Noah's spirit hopefully)
 Jacek: yes it is more subtle but I don't see a problem in this (all the nodes must understand
PASWA)

 DF: the binding approach seems to have more favour
 Jacek: I think both approaches can be taken, we don't have to decide between the two paths
 MarkN: I support going down the binding path but we can do it properly both ways
 Noah: I think I've heard two flavors of the binding proposal
 Noah: to summarize: Herve's approach is "something the binding can use"
 Noah: we actually have to say very little normatively, the bindings have the opportunity to
optimize binary data and we invite bindings to do so
 Noah: we would present one technique available for this
 Jacek: would we specify the HTTP binding with this optimization?
 Jacek: do we still need the DoInclude header?
 Noah: the second thing I think is in discretion of the particular binding
 Noah: should we enhance the current binding or should we publish a competitor to it?
 MarkN: DoInclude is there as a flag to make the message self-describing
 MarkN: I would hope we don't have multiple bindings out there
 MarkN: I wonder if the current HTTP binding can expand in the future (like PASWA, SSL)
 MarkJ: I support extensible bindings, we don't want a new binding for any new combination of
features
 Noah: we could not only upgrade the binding, we could indicate more generally (hopefully not
too complex) how a binding could be extended
[Yves] with Accept-Encoding: and Content-Encoding in HTTP, we don't need to change the binding, it is
an agreement between sender and recipient
 Gudge: I don't want us to redefine how attachments work for every other extension of the HTTP
binding

 DaveO: this is somewhat related to the WSD WG's work on properties and features
 DaveO: WSD wants to describe features independently of their actual implementations
 JacekK: WSD's properties and features are related to SOAP Features, so we might need to make
PASWA into a Feature, therefore a Module, too
 Noah: once we figure out how to evolve the HTTP binding, we could say that the HTTP binding 2.0
supports these and these features, too
 Noah: if a feature can only represent a possible optimization, then PASWA can be a feature but
it still needn't be a module
 JacekK: agrees, so a feature doesn't need a module and then PASWA can be a feature and WSD's P&F
come into play nicely
 DF: one should be able to identify which mechanism is used (for interop and WSDL)

 DF: suggest we agree that we're taking the binding approach, then we can continue in more detail
 MarkN: I think this generally captures the feeling of the group
 MarkN: but have we decided that it needs/deserves to be a feature?
 MarkN: I see it as a feature, expressed in a binding
 DF: so summary: this is a feature and we will express (implement) it in a binding
 no objections to going in this direction

 DF: what are the next steps?
 DF: we could task someone to recast PASWA as a feature (implemented in a binding)
 MarkN: there's no reason we should actually take the xbinc:Include (XMLish) approach in the
binding
 jeffsch: the XML Include wonders if we are interested in using XInclude 1.1
 Noah: I think Include is a fine technology, I don't think it should be necessary/requisite for
implementing this feature
 Noah: any dependency to XInclude should go from one particular binding
 Noah: we should actually consider XInclude when we see what we need in the particular binding
 jeffsch: I don't disagree with the proposal to wait-and-see
 jeffsch: at the abstract level, one shouldn't say it needs XInclude
 jeffsch: the concrete level might require XInclude
 Noah: I'd like us to see the alternatives and then solve the problem we'll have

 DaveO: I think it likely that we'll have a relationship somewhere with XInclude
 DaveO: there might be timing conflicts
 davidF: let's ping them to see if there could be a timing problem

 DF: back to our next steps
 MarkN: 1) let's explore how this is incorporated in a binding, if it requires a new binding or
extends the old one
 MarkN: 2) research what different mechanisms are available to implement the optimization
 Noah: we should specify how different bindings indicate this feature and we should specify our
binding that does that
 Noah: also, where does the Representation element go?
 MarkN: good question
 MarkN: we should describe the feature and one implementation
 MarkN: so there is a packaging problem
 Noah: the Representation thing is actually a module, orthogonal to include
 Noah: we could do that in the same document, but different feature and module
 Noah: I suggest that we make a module (without a separate formal feature) for Representation
 Noah: steps: 1) abstract feature for inclusion, 2) concrete implementation, 3) representation
module
 DF: so we have three chunks of text to do, 1 and 2 should be done in lock-step, the third is
more independent
 no objections to going this way

 DF: volunteers?
 Noah: my time is limited this week, I'm willing to help
 MarkN: I can help on the first two chunks
 Herve: I'm willing to help, but no time this week
 Noah: first two pieces as well
 Herve: as well
 DF: we'll wait with the third

 Jacek: let's close issue 429

 Noah: We should be looking at the XQuery data model

 meeting adjourned



[RRSAgent] ACTION: W3C staff to post revised attachments requirements document [1]
[RRSAgent]   recorded in http://www.w3.org/2003/05/28-xmlprotocol-irc#T18-15-52
[RRSAgent] ACTION: Gudge to send closing email to xmlp-comments and to the originator of issue 428 [2]
[RRSAgent]   recorded in http://www.w3.org/2003/05/28-xmlprotocol-irc#T18-28-35
[RRSAgent] ACTION: DF to contact AT&T, SAP and TIBCO about their IPR statements (for next week) [3]
[RRSAgent]   recorded in http://www.w3.org/2003/05/28-xmlprotocol-irc#T18-34-56
[RRSAgent] ACTION: chair to ping XML Core to determine their schedule for XINclude work [4]
[RRSAgent]   recorded in http://www.w3.org/2003/05/28-xmlprotocol-irc#T19-23-06
[RRSAgent] ACTION: MarkN, Noah, Herve to start work on the abstract feature and conrete implementation
descriptions (report next week) [5]
[RRSAgent]   recorded in http://www.w3.org/2003/05/28-xmlprotocol-irc#T19-34-04
[RRSAgent] ACTION: JacekK to write an updated proposal for closing 429 [6]
[RRSAgent]   recorded in http://www.w3.org/2003/05/28-xmlprotocol-irc#T19-36-36