See also: IRC log
<noah> scribe: noah
MM: Let's leave minutes approval for next week
***Discussing - Check with Plh about the timeline for the new charter (moving to PP, AC review etc...)
YL: Approval of charter will take about a month. Doable by Sept.
MM: What help do you need from us?
<anish2> yves, is sept -- end of sept or start?
<Yves> start, or mid sept
<anish2> k, thx
Doug Purdy of Microsoft joins the call.
MM:
Welcome Doug to the group. He will be working with Gudge, replacing
Jeff Schlimmer as one of Microsoft's representatives
... Also, pending formal confirmation from IBM's AC Rep, Chris
Ferris will be joining Noah as co-rep from IBM.
... OK, so Yves will give me a revised charter draft later this
week. I will share with group and then we'll take it though the
process.
***Discussing - Check process requirements regarding referring to WDs/LC WDs from further advanced documents
YL:
Took me awhile to find references on linking to a doc that's a step
behind. It's good practice but not in formal process. Thus, we are
not bound by WSDL's timeline.
... For WSDL, the spec we're creating is not a crucial reference,
thus they can refer to something that's more than one step
behind.
MM: Right, I had an action to send their schedule, which is CR in Oct, Rec in early 2006
Gudge: They're running at least a month behind, right?
Anish: we have a few issues
being debated. Hard to say exactly when they'll be done. They are
close, and there are few issues, likely none controversial.
... I don't want to suggest a particular date.
MM:
Last week we discussed W3C pushback on our plan for XML 1.1
... We were waiting for Noah to continue.
NM: Noah thanks the group for waiting for me.
<scribe> scribe: cferris
NM: w3c is pushing back on our plan not to support XML 1.1?
MM: Yes
NM:
We should review where we were a year ago.
... Noah interprets last week's minutes as saying that all
envelope constraints from the schema are also in the prose. That
may be true, but Noah recalls that a year ago we didn't want to
count on that being the case.
Gudge: reason schema is
normative is because there are things like type for example soap
encoding
... no constraints not captured in the spec
<anish2> at the ws-addr f2f yesterday, Philippe made a Gartner like stmt that he is 90% sure that the Director would push-back on ws-addr spec that does not support XML 1.1
NM:
we were being more conservative a year ago
... Also, note that we are telling users that they can validate
envelopes with the normative schema. Given that there is no
normative XML schema support for XML 1.1, users lose that ability.
We need at least to do some hard thinking about how to get it back
for them, or whether that is (another) reason not to do XML 1.1 in
SOAP yet.
... recollection was we had long debate about supporting 1.1 w/r/t
interop
... could be intermediate nodes that can't handle it
... at end, we noticed schema was normative but don't want to
count on the fact that all the constraints in the schema are n the
spec
... not taking position yet on behalf of IBM
... sounds like we are close to agreeing on what history is
... as of today, the schema will not validate anything with XML
1.1 in it
Gudge: correct
NM: whats new in schema world is that the WG is in process of preparing a note
<Yves> http://www.w3.org/TR/2005/NOTE-xml11schema10-20050511/
NM:
says "here's something non-normative you can do to promote
interop"
... My recommendation as of now is that we should either (a) go
back to W3C and say we're not supporting 1.1 due to lack of user
demand, interop problems, and lack of ability to supply a schema,
or
... (b) if we do incorporate 1.1, we should do so carefully,
working out the details of both schema support and interop.
... was happy with direction that IBM chose which was not to have
XMLP be one of the first w3C specs to push XML 1.1 support. SOAP
depends on many other facilities, such as schema, and as they come
along we can join them.
<noah> scribe: noah
MH: WSA hit the same problem, and got similar pressure from W3C. After some discussion, we've decided to stay XML 1.0-only.
NM: Has W3C bought into this?
MH:
We had a two-part discussion. Philippe Le Hegaret (spelling?) as
team contact suggested that the director (Tim) might or might not
push back on this issue.
... in second round we heard that the director might well push
back, but we voted in spite of that to stay XML 1.0.
MM: so, we have the same situation. We're just the ones likely to get director pushback sooner.
Gudge: actually, I think our timing is about the same. WSA is very close to CR,
NM: I suggest we do it the day after WSA.
YL: I've said most of what I care about in my email. We already have restriction in the mime type.
<Yves> http://www.ietf.org/rfc/rfc3902.txt
<Yves> <<
<Yves> This document defines the "application/soap+xml" media type which can
NM: RFC 3023 is moving to both XML 1.0 and XML 1.1. Remind me, does our RFC limit to XML 1.0.
<Yves> be used to describe SOAP 1.2 messages serialized as XML 1.0.
<Yves> >>.
YL: yes.
MM:
So, one option is to present argument to director and see what
happens.
... Other is to start on making any changes we need to.
... Opinions?
Gudge: Stick with XML 1.0.
YL: Go to XML 1.1, because it will not change implementations, and all bindings are XML 1.0-only.
MM: How much work is that?
YL:
I made a proposal a year ago.
... we need to craft text describing issue if there is a wish to
apply the schema
<anish2> /me The "application/soap+xml" media type explicitly identifies SOAP 1.2
<anish2> message envelopes that have been serialised with XML 1.0
<Gudge> +1 to Noah's comments about being concerned about deep architectural change and making changes to adopt things that users are not using
NM: I think we have a bit of deep architectural work to do on what sort of error is reflected by an intermediary that fails to relay through an XML 1.0-only binding. We need to decide whether it's a binding level fault, which seems to merit some discussion in the binding framework, or a new form of intermediary failure, in which case we need to spec that fault.
MM: Does Sun have a position?
MH: Could go either way. We see essentially no users asking for this, but on the other hand I don't want to hold back progress if there's a good way to do it. On balance, I'd hold off I suppose.
MM: Iona?
Suresh: we're actually not using
much SOAP 1.2, but in any case our XML use is XML 1.0-only.
... I don't think we have a formal position, but I agree with
Noah's concerns.
anish: we are in a similar
situation to what Mark describes. See no customer requirements. We
do have concerns about architectural implications.
... also concerned about Philippe statement that director is very
likely to send spec back.
... net is we're sort of neutral. If we can do this without
affecting interop, then OK. Note that our binding uses a media type
that is XML 1.0-only anyway.
... we really don't, especially in the addressing space, want to
see the spec bounced.
MM:
I think Canon expressed similar opinion on email list.
... Canon is OK with XML 1.1 as long as current implementations
are still compliant.
... Gudge?
.. I stated my position last week. We've been in this position for
a year. Why change now? The implementation community won't thank
us. I said all this last week.
... SAP is not here?
... SeeBeyond?
Pete: I've been following this,
and agree with most of what I've heard. We agree that there's not
rush.
... if it's easy, I'd be OK with it. Otherwise status
quo.
MM:
should we spend a week looking through archives?
... to guage effort and interop issues?
<scribe> scribe: cferris
NM:
if I care about this at all on behalf of users... anyone wanting to
do this would have to invent their own media type
... there isn't even a normative media type for XML 1.1
... greatly raises the bar on whether we should do this
... greatly complicates the architecture
... we're almost guaranteeing that there's no user value
.. prefer that we do the media type if we are to do this at
all
... little worried that we are approaching this wrongly
MM: we should do more than just this surface fix?
NM: to sit in the middle that we do some work that keeps the organization happy, one would hope they come back to us for the media type
<noah> scribe: noah
anish: I'm not sure I see it that way. An artful choice "in the middle" may be just what we need.
Gudge: I'm with Noah on this.
MM:
Seems like we have one member saying "stick at XML 1.0", everyone
else saying let's at least take another look.
... Yves and Philippe, do you think we have sufficient grounds to
make the case to Tim?
YL: no idea
<anish2> anish: to be clear, i'm not necessarily advocating the 'in the middle' position. As I said, I'm neutral at this point. If XMLP and ws-addr have to essentially do tha same thing and status-quo is going to delay ws-addr, then I would prefer the middle ground, else status quo.
MM: Gudge, would you lie down in the road if we tried this?
Gudge: I spent a half year last year on this, and we came to a decision. Nothing's changed. I don't want to do it again. I'd push back now.
MH: Yes, push back.
Gudge: it's not all that critical we publish PER. Rec and errata are out there.
<scribe> scribe: cferris
NM:
is there a possibility that Tim would be receptive to an informal
discussion?
.. do you think that Tim has a gut feel from the implementers and
the users?
YL: those arguments were put on the table in the team discussion
NM: some issues yes, a few no?
YL: yes
<noah> scribe: noah
MM:
opinions?
... Gudge, sounds like you're ready to "just say no"
Gudge: I feel I've been well understood.
<scribe> ACTION: Mike Mahon to talk to Mark Nottingham about whether WSA and XMLP should coordinate response on XML 1.1 [recorded in http://www.w3.org/2005/07/20-xmlprotocol-minutes.html#action01]
<scribe> ACTION: Yves to check with Philippe Le Hegaret to see whether W3C staff would be receptive to combined WSA/XMLP response on XML 1.1 [recorded in http://www.w3.org/2005/07/20-xmlprotocol-minutes.html#action02]
<cferris> NM: thinks that there are some deep architectural issues
NM: Thank you for deferring discussion to get IBM's input. The net of our position is: we are glad to support a commitment on behalf of XMLP to provide function in the needed space, I.e. for one way messages, related MEP and binding support, etc.
<cferris> NM: thinks we should defer decision as to form factor: Rec vs WG Note
<cferris> MM: but there may be charter implications
NM: we do not at this point want to bake in a decision on a particular technical direction. There are some promising ones on the table, but they need detailed discussion.
<cferris> MM: if we chose the Rec path, we concluded that we could begin the work while the charter is being worked out
NM: as to form, important functions should wind up in a Rec, IMO, but I'd prefer to decide on the right form for publishing our results once we decide on the technical details of what we're trying to publish.
YL: Process-wise, doing Notes let's us work with just a charter extension. A Rec. requires recharter.
MM: is IBM OK with voting today to do something on a Rec track?
NM: I want to check with Chris, but I think so if that's what the group wants to vote on. I could also vote for something vaguer that said we'll decide later on the merits when we see what we've designed.
CF: Well, we are probably not opposed to a new Rec, but we have some process within IBM for buying into that. Republishing the existing SOAP Rec raises fewer issues.
MM: Chris, how long to get a formal answer from IBM?
CF: One week or three, depending on whether I can get it on a call in an hour. We have strategy calls every two weeks and one is in a few mins.
Gudge: Microsoft supports this work, but we want the scope very clearly defined. REC track is appealing in part because the charter process forces us to think that through clearly, and in part because we get the patent policy issues right.
anish: Do I think that one-way MEP and binding thereof is a crisp enough scope
Gudge: no, not clear enough. Doesn't bound how many we produce, etc.
MM: Is IBM's position that the conservative approach is to keep things open as to Rec or note
NM:
Note really. Rec track looks best, but we do have to doublecheck
internally.
... Suggestion, IBM can vote for REC track today as a tentative
decision, with the the understanding that changes of position are
in order for approx next two weeks. I really don't think we will
object.
MM:
Polling companies.
... Canon = yes Rec track
... Iona = yes open
Gudge: actually, Canon didn't say rec track or not.
MM:
Canon is therefore yes but no word on Rec track.
... Microsoft yes REC
... Nokia Yes Rec
... Oracle Yes Rec
... SeeBeyond: Yes Rec
... Sun Yes Rec
... IBM Yes Rec (will doublecheck)
... seems that everyone is leaning yes - rec. Suresh, can you
doublecheck Iona would be OK with that? Puts you in same
doublecheck status as IBM.
... any other comments on this?
MM: did you move discussion to email
Anish: we started, but not on
distApp
.. actually, I thought I did that. Will doublecheck and send to
XMLP as necessary
<scribe> ACTION: Anish to make sure WSD/Async discussion is going to distApp [recorded in http://www.w3.org/2005/07/20-xmlprotocol-minutes.html#action03]
[NEW]
ACTION: Anish to make sure WSD/Async discussion is
going to distApp [recorded in http://www.w3.org/2005/07/20-xmlprotocol-minutes.html#action03]
[NEW] ACTION: Mike Mahon to talk
to Mark Nottingham about whether WSA and XMLP should coordinate
response on XML 1.1 [recorded in http://www.w3.org/2005/07/20-xmlprotocol-minutes.html#action01]
[NEW] ACTION: Yves to check with
Philippe Le Hegaret to see whether W3C staff would be receptive to
combined WSA/XMLP response on XML 1.1 [recorded in http://www.w3.org/2005/07/20-xmlprotocol-minutes.html#action02]
[End of minutes]