Derived from http://www.w3.org/2003/02/11-xmlprotocol-irc.html. Meeting agenda at http://www.w3.org/2000/xp/Group/3/02/CRtelcon.html
[scribemj] the main focus of the march 6-7 face-to-face will be on the attachment feature work
[scribemj] minutes of Feb 5 telcon are approved
[scribemj] ACTION: add DavidF to current action to get confirmation from DIME and SwA that we can reuse the spec
[scribemj] when Colleen is finished with her QA review, DavidF will put it on the agenda
[scribemj] ACTION: Jacek will provide his RDF Core review by weekend of Feb 15
[scribemj] Nilo will have Part 0 changes reflecting Susan Lesch's comments by Feb 21
[Gudge] http://www.w3.org/2000/xp/Group/2/06/LC/edtodo.html
[scribemj] ACTION: Nilo will have Part 0 changes reflecting Susan Lesch's comments by Feb 21
[scribemj] ACTION: Part 1 editors will incorporate changes up to Feb 11 by Feb 21
[scribemj] The editors propose putting even small changes in the change log and highlighting larger changes.
[scribemj] After Feb 21, the editors will collect potential changes to bring to the face-to-face (and not change the document after Feb 21).
[scribemj] We will be making a go/no-go decision of Part 0-2 at the face-to-face.
[scribemj] ACTION: DavidF will contact Anish ASAP to determine status of test collection.
[scribemj] Members will be polled by the chair on any IPR disclosures as we go through various stages.
[scribemj] The application/soap+xml media type needs to be registered with IETF.
[scribemj] ACTION: Yves will research the registration process by Feb 19 -- contact Joseph Reagle.
[scribemj] ACTION: DavidF will contact Mark Nottingham re media type registration as well.
[scribemj] Decided to publish n11n as a note. (no objections)
[scribemj] ACTION: To n11n editors and W3C staff to publish n11n as a note.
[scribemj] Decision to publish the Abstract Model as a WD that the WG intends to do no more work on it. (no objections)
[JacekK] ACTION: To DavidF and W3C staff to publish AM document.
[DavidF] discussion on issue 411 ....
[scribemj] Gudge says that intermediaries should preserve prefixes.
[Gudge] I think there is also a cut and paste error with 'The[in-scope namespaces] property of element information items MAY be changed or removed.'
[Gudge] I think it should only say 'MAY be changed' ( the 'or removed' should be removed ;-) )
[Gudge] Prefixes are also in the Infoset
[Gudge] There is a[prefix] property on EII and AII
[DavidF] http://www.w3.org/TR/2002/CR-soap12-part1-20021219/#soapinterminfoset
[DavidF] proposed s/The[in-scope namespaces] property of element information items MAY be changed or removed.
[DavidF] /The[in-scope namespaces] property of element information items MAY be changed or removed.
[DavidF] remove the "or removed"
[Gudge] Attribute information items MAY be added to the[namespace attributes] property of the SOAP Envelope element information item.
[Gudge] Note this will change the[in-scope namespaces] property of the SOAP Envelope EII and any descendants.
[Gudge] The[in-scope namespaces] property of element information items MAY be changed or removed.
[Noah] The[in-scope namespaces] property of element information items MAY be changed or removed.
[Gudge] All namespace information items in the[in-scope namespaces] MUST be preserved. Additional namespace information items MAY be added.
[Noah] All[namepace info items] in the[in-scope namespaces] property of element information MUST be preserved. Additional such items may be inserted.
[Noah] ACTION: Editors to revise realy rules to say: " All namespace information items in the[in-scope namespaces] MUST be preserved. Additional namespace information items MAY be added."
[Noah] That was "relay", but I'm not remembering the syntax to update an action.
[Yves] it will be ok in the admin page
[JacekK] ACTION: add a note to clarify that NS prefixes must be preserved (as a result of the rules)
[JacekK] ACTION 11= Editors to add a note to clarify that NS prefixes must be preserved (as a result of the rules)
[scribemj] ACTION: Gudge will respond to commentator on issue 411 and to xmlp-comments
[Noah] ACTION 10= Editors to revise relay rules to say: " All namespace information items in the[in-scope namespaces] MUST be preserved. Additional namespace information items MAY be added."
[scribemj] No pushback has been received on any previous resolutions.
[scribemj] Jacek gives a summary on the implementation reports...
[scribemj] 49 implementation features in a few categories
[scribemj] 11 green features (implemented and testing)
[DavidF] features listed in http://www.w3.org/2000/xp/Group/2/03/soap1.2implementation.html
[scribemj] 3 features with at most one implementation
[scribemj] 11 features with no interop traces
[scribemj] 23 features with some interop traces
[scribemj] Implementers are working twice weekly.
[scribemj] There will be discussion at the upcoming soapbuilders face-to-face.
[DavidF] 3 features not implemented - SOAP Response MEP (2), GET method in HTTP binding (1)
[scribemj] Hope that most features will be green at that point.
[scribemj] ACTION: MarcH will check with internal implementers vis-a-vis participating in the feature page.
[DavidF] discussion on "what happens if no impl evidence for SOAP Response + HTTP GET?"
[DavidF] markJ notes that WSA thinks REST style is useful and would not want it to disappear
[DavidF] DF asks whether he would have backing of WG to go to TAG and note that sufficent REST impl evidence may not be forthcoming
[scribemj] Noah thinks we should signal the TAG regarding the nature of the disconnect with soapbuilders.
[scribemj] ACTION: DavidF will try to pursue any avenues to get more evidence for
[scribemj] the 3 features above.
[JacekK] ACTION: David to draft an email to the TAG about the issues around HTTP GET binding
[scribemj] No one volunteers to do sanity check on implementer's data.
9 Attachment Feature Requirements discussion
[scribeJK] (it is possible that the call today is interrupted today because of MIT systems outage)
[scribeJK] MarkJ: we've had six meetings in which we worked on the requirements, currently we have 23 reqs and 1 draft req
[DavidF] http://lists.w3.org/Archives/Public/xml-dist-app/2003Feb/0076.html
[DavidF] is the most recent AFTF Reqs list
[scribeJK] MJ: we'll try to reuse an existing packaging scheme if possible
[scribeJK] MJ: the requirements are loosely structured into four groups
[scribeJK] MJ: we have requirements related to WSDL which is itself a moving target
[scribeJK] MJ: some more interesting requirements relate to streaming
[scribeJK] MJ: R29 has generated the most discussion
[scribeJK] MJ: R29 deals with the attachment data being a part of the message infoset
[scribeJK] MJ: we'll talk about this issue later
[scribeJK] MJ: further requrements deal with meta-data like MIME content-type
[scribeJK] MJ: the rest of the requirements deal with referring to the attachments
[scribeJK] DavidF: we have on our agenda the WSDL-related reqs and R29; we might want to add R6 and R11
[Noah] I sent a note to the list this morning responding to a David Orchard question relating to AFTF R6
[scribeJK] MJ: R6 has some philosophical issues in it
[scribeJK] DavidF: are there questions on the other requirements?
[scribeJK] MJ: a set of usecases would be useful when creating requirements, we don't have usecases, so our work may be somewhat affected by it
Brief overview of R6 ....
MJ: first sentence is a stake in the ground
MJ: there is a view that attachments may be just attached web
resources
MJ: in some usecases that needn't be true
MJ: this may tie to various URI schemes, like SwA's cid:
Noah: DaveO has sent another batch of comments, it touches the
differences between URIs and URIrefs
Noah: I have strong concerns.
Noah: using HTTP URI scheme for attachments is IMO a mis-use of
the scheme
Noah: we don't need to be a web-cache, IMO it's unduly
complicating our thinking
Noah: IMO all this raises serious questions
Noah: I think we have a good way to build web-caching approach
above, more robustly
DF: people on this call having strong opinions the other way?
Gudge: if I have a SOAP envelope with an HTTP URI in it, it must
not refer to an attachment?
Noah: not directly, possibly via a feature
Gudge: so we'd have to make up URIs?
Noah: yes, and it would allow us to carry ten different snapshots
of one resource in attachments
Gudge: SwA doesn't mandate cid: scheme, so Noah thinks it's broken
MJ: is it clear that the attachments are representations and not
resources?
MJ: or can a feature turn them into resources?
Noah, MarcH: resource is an abstract thing
MJ: could you think of an attachment as a "serialization" of a
resource?
Marc: I think cid: is a good idea, we might add
content-location-like mechanism to allow the other,
web-cache, approach
David: WSDL-related reqs R15 and R24....
MJ: there is a possible coordination issue, who should take it up?
DavidF: do the RDF guys want to describe attachments?
No response.
DavidF: MJ thinks that there are a couple questions. One: if we
think about attachments, should we think about the
abiility to describe the attachments in a broader sense
than WSDL?
MJ: also: should we be the ones to say how we think we should be
described in WSDL?
Marc: we're expecting the Desc WG to create a SOAP binding, so we
should punt WSDL description of attachments to that group, too.
Noah: I think the burden on us is to demonstrate reasonably that
our product is describable
Noah: we could say that we're likely to be describable in
reasonable description languages; if we see problems in WSDL
we should tell the WSDesc WG about it.
Marc: I'm not saying that it doesn't matter if whatever we come up
with is not describable
DavidF: we might want to raise these questions on the CG
MJ: if there are more ways to describe attachments, we won't get
interop until it's standardized
DavidF: proposal: we'll go to CG showing the problem and
suggesting somebody should take it on
DavidF: we need this sooner rather than later
DavidF: will this course of action resolve the group's concerns
about the WSDL-related reqs?
MJ: so we can keep the requirement R15? Should we scrap R24?
DavidF: it seems to be logical.
No other comments.
[JacekK] ACTION: DavidF to go to CG to say that we are working on the Attachment Feature reqs and that we believe there will be interaction with WSDL and we are mindful of that but we won't do any design work; we think WSDL group should take it on board to describe attachments
[scribeJK] DF: we'll move on to R29
[Noah] David & Gudge: If Gudge is agreeable, I suggest he go first and outline what he perceived to be the requirement. Then I can respond with my concerns. Otherwise, I'll be in the position of trying to approximate a summary of his position so I'll have something to react to. Thanks.
[scribeJK] jeffsch: we might also want to spend some time on R11
[DavidF] ok w/ me
[DavidF] gudge?
[Gudge] yes
[scribeJK] Noah: I can go over that very briefly if there's interest in this
[DavidF] thnx - gudge goes 1st, then NM
[Gudge] makes sense to me
[scribeJK] Noah: the interpretation of R11 depends on what one wants to do
[scribeJK] MH: I missed when this one was discussed... My understanding of this req is that, e.g. if you have a SOAP message and a JPEG image you can send the image first
[scribeJK] MJ: there were usecases like that
[scribeJK] Noah: we also discussed the usecase that the first bytes of the package be the SOAP message
[scribeJK] DF: we need some clarification of R11 at minimum
[scribeJK] DF: I'd like to move now to R29, Gudge will present first
[scribeJK] Gudge: R29 says that there must be an infoset that you can construct from the serialized form of the message
[scribeJK] Gudge: that's true today with plain SOAP Envelope in the message
[scribeJK] Gudge: I want to go further than that and I think the spec supports this
[scribeJK] Gudge: any information that travels with the message should have some representation in the infoset
[scribeJK] Gudge: the infoset is the basis to some specifications and those specifications can then apply to our spec easily
[scribeJK] Gudge: e.g. we could use XML Schema to describe attachments, too
[scribeJK] Gudge: if we define a different data model, we'll have to handle processing models for intermediaries etc.
[scribeJK] Gudge: I'm thinking of something akin to what XInclude does - an infoset is transformed into another with more things in it
[scribeJK] Gudge: then we won't have to do anything for WSDL because that uses XML Schema already
[scribeJK] Noah: I have to restate what I think Gudge is proposing:
[scribeJK] Noah: I think this is a big change to SOAP as a whole
[scribeJK] Noah: I think Gudge says: the goal is to unify all the information in the message into a single infoset for various reasons
[scribeJK] Noah: ...if we want to send a JPEG, it will be modeled as XML Schema binary type, it will show up as children of some element in the envelope
[scribeJK] Noah: Gudge - would there be a collection of parts like there is a collection of headers?
[scribeJK] Gudge: it doesn't matter to me
[scribeJK] Gudge: that's a conceptual thing rather than a serialization thing
[scribeJK] Noah: we've got data modeled as characters in the infoset; bindings have always had a lot of power in transmitting the infoset so they might transfer some of the data as an attachment for efficiency
[scribeJK] Noah: Gudge says that SOAP message is an XML envelope; I don't think it's been so, really
[scribeJK] Noah: we've always assumed that there may be information outside the infoset that travels with the message
[scribeJK] Jacek: is Noah worried about people trying to transfer the infoset as XML without attachments?
[scribeJK] Noah: not at all - the problem is about not knowing where the attachments are in the infoset
[scribeJK] Noah: we make no use of the notion of a typed infoset, this may come close
[scribeJK] Noah: a binding might want to look for attachments and it might need typing to do it
[scribeJK] Gudge: we might use a qualified attribute to mark attachments
[scribeJK] Noah: now you're duplicating typing
[scribeJK] Noah: so this takes us into using typed infoset; is XML Schema validation a legitimate way of typing it? More questions like that...
[scribeJK] DF: let's involve the rest of the group, too - any comments?
[Gudge] I disagree that any changes are really required to SOAP 1.2 Part 1
[scribeJK] MarcH: I may have missed something... I think Gudge's idea is intriguing but it may have practical problems.
[scribeJK] MH: Gudge's suggestion can bring XML Digital Signature which may remove the performance gains by coding everything in base64 anyway.
[scribeJK] Gudge: the expensive part is decoding so there would still be a big gain
[scribeJK] Noah: it would still be very expensive in some cases
[scribeJK] Noah: it would push you into a truly binary infoset and I'm afraid it's too deep at the moment
[scribeJK] Gudge: there are definitely issues with signatures (performance concerns etc.) but I'm willing to pay this cost and there may be ways of mitigating it
[scribeJK] Noah: can this be done without changing part 1? Changing what SOAP is? I believe these changes are huge abstractly.
[scribeJK] MJ: I share Noah's misgivings about the potential ripple effects
[scribeJK] MJ: If you want a binding with lots of extensibility, we have no way of describing the processing model for that
[scribeJK] Noah: we spent major time discussing this, features may benefit the processing model
[scribeJK] Noah: we're now in CR and in discussing requirements for a concrete realization of a feature we're reopening the issues
[scribeJK] Noah: the boundary may be moved by features and dynamic bindings
[scribeJK] s/Noah/MJ/
[scribeJK] DF: comments from other members?
[scribeJK] DF: the discussion on 29 seemingly continues
[scribeJK] DF: it may be that more time in the TF is necessary, it's possible that the TF cannot agree on an answer
[scribeJK] DF: the TF's task is not necessarily to come up with the right answers
[scribeJK] DF: the TF may come up with options for some requirements, the WG will ultimately decide
[scribeJK] DF: we'll have the f2f meeting and the TF's product will be input to that
[scribeJK] DF: after break, let's spend 15 minutes on how the AFTF will move forward
[scribeJK] DF: then let's speak about rechartering and AOB
[DavidF] agenda is at http://www.w3.org/2000/xp/Group/3/02/CRtelcon.html
[marc] /nick marc_scribe
[scribe_ma] How to move forward with AF
[scribe_ma] determine starting points
[scribe_ma] obvious candidates DIME and SwA (MIME)
[scribe_ma] MJ: may be possible to use parts from each rather than wholesale adoption
[scribe_ma] DF: looking at SwA and DIME as starting points modulo IP concerns
[scribe_ma] JS: DIME is not an attachment scheme per se, shoudl use WS-Attachments instead
[scribe_ma] DF: does it make sense to start work measuring the technologies against the requirements
[scribe_ma] MJ: expected this to start once requirements polished off
[scribe_ma] MH: start with requirements, then work out which spec is best starting point
[scribe_ma] MJ: agrees with this approach
[scribe_ma] NM: get a sense from developers which is preferable
[scribe_ma] JI: test requirements or solutions with developers
[scribe_ma] NM: the latter or maybe a two pronged effort
[scribe_ma] DF: should we start this work now ?
[scribe_ma] NM: not sure how we would approach this - ask tag, soapbuilders, ...
[scribe_ma] MJ: likes the idea of getting broader input on the requirements
[scribe_ma] DF: how should we publish these requirements - previously our requirements were in the form of a WD, we could turn our attachments requirements into a draft and request a review
[scribe_ma] MJ: shouldn't be too hard to do
[scribe_ma] NM: shoudl we wait until our requirements (R29) firm up
[scribe_ma] DF: yes, was thinking that post F2F woudl be the right time
[Noah] Clarification for the minutes of what I was trying to say:
[scribe_ma] MJ: in parallel we could work on WDifying the doc
[Noah] Q. Are we publishing a WD right now or perhaps in a few weeks? A. (from DF): not now
[scribe_ma] DF: AF work continue in task force or be expanded more widely ?
[scribe_ma] MJ: Different set of people may wish to participate
[Noah] Good. Two reasons I like the delay (1) I think we have some very rough issues in the current version, doing a bit of cleanup will minimize controversy and (2) I think there's a good chance that if we do go with the DR29 Infoset formulation (which I'm still not sold on), we may want to put some of it in a revision to the Att. Feature working draft, and republish that in coordination with the concrete implementation requirements.
[scribe_ma] MJ: task force is lean and mean, but borader group means get more input
[Noah] The above is what I believe I said on the phone a few minutes ago.
[scribe_ma] MJ: good to have everyone in the discussion at the start
[scribe_ma] DF: no need for actionable agreement right now, will discuss in F2F
[scribe_ma] DF final bullet point
[scribe_ma] MJ: may not be possible to do parts of design separately
[scribe_ma] DF: suggest we leave this discussion for now
[scribe_ma] DF: anything else we should think about
[scribe_ma] MH: notes that WS-I basic profile 1.1 will be based on SwA. Assuming this is adopted could be an arguments against us going off on another tangent
[scribe_ma] NM: thinks WS-I is one of the constituents to think about
[scribe_ma] MJ: WS-I choice of SwA may be more due to constraints of having to choose between available techs rather than the technical merits
[JacekK] (re. items for a new charter) my last list is at http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2002Dec/0049.html [JacekK] the thread starts with http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2002Dec/0018.html [scribe_ma] DF: what things should be in recharter ? [scribe_ma] JI: limited scope: attchaments, house keeping for spec we have at the moment [Gudge] +1 to JohnI proposal [scribe_ma] JK: finish attachments, work on errata - might consider additional bindings, MEPs, correlation, routing, reliability [scribe_ma] MJ: would be good to have normative binding corresponding to description groups MEPs [scribe_ma] NM: should consider these things and say no to 90% [scribe_ma] NM: if there's anything that's needed that can't be done without modifying SOAP 1.2 then we shoudl consider those [scribe_ma] MJ: WSA many things are too small to justify W3C process [scribe_ma] MJ: WSA conclusion that a group should consider these things [DavidF] MH: perceives there being technologies being re-invneted, and these should be in our next charter [scribe_ma] JK: doesn;t see any need yet for SOAP 1.3 (as discussed by Noah), supports MH comments [scribe_ma] NM: clarifies that he doesn't see a need to SOAP 1.3 yet but that if such things do occur then they shoudl be a priority for this group [scribe_ma] NM: XML Core WG could be a good model - don't do lots of peripheral things, concentrate on core spec evolution [scribe_ma] DF: 3 view points. concrete next things to work on, group keeps going in quiet state taking on work that meets some criteria (e.g. Noah's if it break SOAP 1.2) [scribe_ma] final view point similar but criteria is that group would work on things that are being reinvented in multiple places [scribe_ma] MJ: doesn't think there's a big difference between first and last [scribe_ma] MH: difference is related to foundational things vs higher level capabilities, e.g. msg ID vs reliability [scribe_ma] DF: not sure best way to proceed, notes that any new charter woudl need to be ratified by AC [scribe_ma] JI: timescale ? [scribe_ma] YL: charter runs out at end of 2003 [scribe_ma] JI: recharter replaces existing charter or starts once existing expires ? [scribe_ma] DF: could work either way [scribe_ma] NM: could form WG to take on spec maintenance and future changes to SOAP, other group to handle things that don;t require changes in core spec [Gudge] +1 to Noah's suggestion above [scribe_ma] JI: don;t want to recharter group to pick off problem that will boil an ocean. Marc's proposals don;t fall into this category. If we could have a mechanism to accept new short term pieces of work then woudl support that [scribe_ma] NM: worried about WG not working on suites of technology (e.g. reliability requires msg ID) shoudln;t bite of small fragments [scribe_ma] DF: take this discussion to email, not in position to decide right now. Member discussion on member list [scribe_ma] DF we have reached end of our agenda [Gudge] cheers from the public gallery [scribe_ma] DF: unless anybody has soemthing for tomorrow then we won;t hold tomorrow's meeting [jeffsch] +1 to no telecon tomorrow (at least not starting at 7:30 am pacific) [scribe_ma] DF: silence taken as assent [scribe_ma] next telcon next week [scribe_ma] meeting adjourned [RRSAgent] I see 16 open action items: [RRSAgent] ACTION: add DavidF to current action to get confirmation from DIME and SwA that we can reuse the spec[1] [RRSAgent] recorded in http://www.w3.org/2003/02/11-xmlprotocol-irc#T15-49-39 [RRSAgent] ACTION: Jacek will provide his RDF Core review by weekend of Feb 15[2] [RRSAgent] recorded in http://www.w3.org/2003/02/11-xmlprotocol-irc#T15-54-55 [RRSAgent] ACTION: Nilo will have Part 0 changes reflecting Susan Lesch's comments by Feb 21[3] [RRSAgent] recorded in http://www.w3.org/2003/02/11-xmlprotocol-irc#T15-57-24 [RRSAgent] ACTION: Part 1 editors will incorporate changes up to Feb 11 by Feb 21[4] [RRSAgent] recorded in http://www.w3.org/2003/02/11-xmlprotocol-irc#T15-59-11 [RRSAgent] ACTION: DavidF will contact Anish ASAP to determine status of test collection.[5] [RRSAgent] recorded in http://www.w3.org/2003/02/11-xmlprotocol-irc#T16-10-55 [RRSAgent] ACTION: Yves will research the registration process by Feb 19 -- contact Joseph Reagle.[6] [RRSAgent] recorded in http://www.w3.org/2003/02/11-xmlprotocol-irc#T16-19-41 [RRSAgent] ACTION: DavidF will contact Mark Nottingham re media type registration as well.[7] [RRSAgent] recorded in http://www.w3.org/2003/02/11-xmlprotocol-irc#T16-20-11 [RRSAgent] ACTION: To n11n editors and W3C staff to publish n11n as a note.[8] [RRSAgent] recorded in http://www.w3.org/2003/02/11-xmlprotocol-irc#T16-21-48 [RRSAgent] ACTION: To DavidF and W3C staff to publish AM document.[9] [RRSAgent] recorded in http://www.w3.org/2003/02/11-xmlprotocol-irc#T16-23-24 [RRSAgent] ACTION: Editors to revise relay rules to say: " All namespace information items in the[in-scope namespaces] MUST be preserved. Additional namespace information items MAY be added."[10] [RRSAgent] recorded in http://www.w3.org/2003/02/11-xmlprotocol-irc#T16-42-34 [RRSAgent] ACTION: Editors to add a note to clarify that NS prefixes must be preserved (as a result of the rules)[11] [RRSAgent] recorded in http://www.w3.org/2003/02/11-xmlprotocol-irc#T16-45-38 [RRSAgent] ACTION: Gudge will respond to commentator on issue 411 and to xmlp-comments[12] [RRSAgent] recorded in http://www.w3.org/2003/02/11-xmlprotocol-irc#T16-46-32 [RRSAgent] ACTION: MarcH will check with internal implementers vis-a-vis participating in the feature page.[13] [RRSAgent] recorded in http://www.w3.org/2003/02/11-xmlprotocol-irc#T17-08-29 [RRSAgent] ACTION: DavidF will try to pursue any avenues to get more evidence for[14] [RRSAgent] recorded in http://www.w3.org/2003/02/11-xmlprotocol-irc#T17-23-52 [RRSAgent] ACTION: David to draft an email to the TAG about the issues around HTTP GET binding[16] [RRSAgent] recorded in http://www.w3.org/2003/02/11-xmlprotocol-irc#T17-24-47-1 [RRSAgent] ACTION: DavidF to go to CG to say that we are working on the Attachment Feature reqs and that we believe there will be interaction with WSDL and we are mindful of that but we won't do any design work; we think WSDL group should take it on board to describe attachments[17] [RRSAgent] recorded in http://www.w3.org/2003/02/11-xmlprotocol-irc#T18-52-40