W3C XML Protocol Working Group teleconference, 7 May 2003

1. Roll call

Present 16/13 Excused Regrets Absent

2. Agenda review, and AOB

AOB -
JohnI: I put a posting for a response to XKMS, I would like to get some
feed back from the WG.
DavidF: Let us put that under agenda item #5
David: I am also soliciting suggestions from WG members for a time/place
for our next F2F.

3. Approval of April 30 telcon minutes

No objections, approved.

4. Review action items, see

[http://www.w3.org/2000/xp/Group/Admin/#pending]

5. Status reports (11.20 + 10)

-- Creation of response to XML Core and XML Schema WGs regarding XML and
XML Schema subsets/profiles
DavidF: Noah did post something on the ML. But no follow on.
Noah: I proposed based on what we discussed last week. The questions are:
1) do we want to take position at all about subsetting. 2) if we want to
encourage them, do we want to provide guidance on it. I am not sure if we have
 consensus even on the questions.
DavidF: one way to proceed here would be to spend a little time now, on
what the answers to your questions are. This would encourage some discussion on
the list.
DavidF: Noah, you have a position on the questions. Why don't you give your
 opinions on it.
Noah: It seemed to me that people were very quick to make the leap (because
of SOAP) that subsetting was a good thing. My view is that no XML apps use
all the features (eg, not using attributes - one can write a parser to ignore
 attrs.) - does that mean that we should have a cosmic subset that do not
 have attributes? I am not sure this is the right thing to do. I am not
sure that every application should allow every XML feature, but this does not
 mean that we should have subset. I am not convinced that subsetting is a
 good idea.
David: do other people have other positions?
MarkJ: are we then not preaching like we are practicing?
Noah: it is something like a application saying that there must be a
 "real-estate" tag, that does not mean that this is a subset. We have not
 changed XML, we just decline to put PIs and DTDs. This is similar to a
 real-estate application restricting documents to the "real-estate" tag.
MarkN: I am sympathetic to Noah arg. but we are not applications. It does
seem a bit like a subset.
Noah: XML does not allow you to send general XML inside XML.
MikeC: I agree with Noah, that it was not the intent of XMLP to design a
 subset, but along the way we have stumbled on the fact that you cannot
send arbitrary XML with soap. A well-formed XML, but have things that SOAP
 processor will choke on - this is a interop problem. Having something
that XML tool dev and vendors would flag and check on would improve interop.
DavidF: looks like this is a good introduction to the topic. We should take
 this to ML. I would ask MikeC, Noah, MarkJ to send their view to
dist-app.

-- Creation of "Q+A" regarding SOAP 1.2 in a WSDL 1.1 environment
DavidF: I started the thread posing the question. One response from Noah.
Noah can you summarise your position.
Noah: there is a perception that the only WSDL, people have seen deals with
 SOAP 1.1 and we are coming with SOAP 1.2. This might be a problem
 with adoption of SOAP 1.2. I don't think we have a problem here. SOAP
itself does not have a dependencies on WSDL. There are usage scenarios where
WSDL is not required. But WSDL is central to WS. SOAPBuilders have been able to
come up with a WSDL that can support SOAP 1.2
MikeC: I don't think there is a problem here, because of the what Noah
 mentioned. It is bit of a PR problem for W3C. So much of SOAP traffic is
 generated from WSDL. So the perception is to ask what do we do until WSDL
1.2 comes out.
<Anish points to URL that was posted during the previous concall - that
allows SOAP 1.2 to be used with WSDL>
David: we could send an email to WSD and ask them what they want to do. We
 would like get WSD's opinion and find out how they want to position it.

XKMS (re. John's review of XKMS Last Call):
JohnI: looks pretty good. In their intro there are a couple of sentences
which I would like to get comments on. This was posted on the list. (It
requires use of SOAP 1.1 and 1.2 is recommended). Since we are entering PR 
and 1.1 is only a note, should we require SOAP 1.2?
DavidF: What is the estimated duration of LC?
DavidF: May 15 was our deadline. The deadline is probably a week from that
 time. I would think that until we go to Rec, we cannot really ask them to
 make that change. We can tell them when we go to rec and ask them to take
 that into consideration.
Noah: I thought that W3C allowed you to be one-step ahead.
Yves: their requirements is to require soap 1.2 if we reach CR.
DavidF: so looks are XKMS already has a requirement that requires them to
 support SOAP 1.2
Noah: +1 to JohnI. We should also ask them to downgrade SOAP 1.1
DavidF: 1.2 is a must and we should say that 1.1 needs to be downgraded.
 JohnI can you provide that feedback (in collaboration with Yves).
JohnI: I will get the final response together and post it to the private
list, by friday.
DavidF: as long as there is no push back send it to XKMS by 13th (tuesday).

-- Registration of "application/soap+xml" media type, see
http://www.w3.org/2002/06/registering-mediatype.html
<Some feedback sent to the list>
MarkN: whether the media-type is specific to SOAP 1.2 or can it be used for
 anything. They would like to use it with SOAP 1.1. Because SOAP 1.2 is
not backward compatible with 1.1, it should be only 1.2
Yves: media-type is only a hint. The version can be detected by looking at
the envelope.
DavidF: what does our spec say?
MarkN: I am not sure, but I think it does because of reference to the
 media-type reg.
Noah: we have a set of versioning rules in the spec. There is a discussion
in TAG on this about how normative media-type is. I am not quite sure which
way to go.
MarkN: 1.1 says that you should use text/xml. I think we should pose the
 question to the IETF media list and TAG and get their expert opinion.
MarkN: there was email exchange between MarkB and the originator. I will
 forward it if there is something substantial.
DavidF: we will take this to email. is there a deadline?
Yves: it will be good a send a new draft and start a discussion on it.
MakN: i don't think there is an urgency.
<Action to MarkN>

-- PR
Update from DavidF:
We have gone PR. We have headline billing on W3C mainpage. We are now entering
the review period. AC reps should send in their comments. The sooner the AC
reps send their comments the sooner we can get through any issues. A new PR
issues list to be set up. We will also need an editor's copy.
Issues from the holding bucket get into the PR list.
<action to W3C staff>

6. Attachments

-- Moving forward with Attachments: order of activities, reconciling with
Attachment feature, issue creation, editing the document(s)
-- Attachment requirements, see
http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2003Mar/0027.html.
-- Formulation of critical questions against PASWA.
-- The PASWA ("Proposed Infoset Addendum to SOAP Messages with
Attachments") proposal at
http://lists.w3.org/Archives/Public/xml-dist-app/2003Mar/0060.html

DavidF: I talked to Danny w.r.t to copyright and IP situation. We decided
that even if we don't have all the stmts we will take it in good faith - they
are en route and are ok. As chair I am allowed to make that decision - to use
the PASWA proposal as a starting point. There are number of activities that
are open - 1) requirements, 2) formulation of the critical questions
(effectively they become issues), 3) the actual proposal itself.
 There are other things - reconciliation with the att. feature doc - which
is different model than the PASWA model. Some admin stuff about bringing the
doc on board and assigning editors to it.
 I propose that we start with working on the requirements. I think
 critical questions/issues is also what we should be generating and
resolving.  Thoughts?
MarkJ: One of the places we got to was in the middle of R6, R7, R12 which
hinged on deeper understanding of the model. We should have some clarity on the
 model before going on to the requirements. The fundamental issue was, the
 framework was at the binding level or would it stand on its own. We could
do it either way. We could dive into the req. and pause if we encounter it,
or the other way around.
Noah: I would like to suggest that my note is raising a req. at two levels.
1) whatever proposal we adopt needs to be presented in terms of SOAP 1.2
 (feature/module/binding) - this is independent of the model etc. 2) Is
there a circularity within the proposal. But (1) is really the most important
 thing.
DavidF: in order to recast it in SOAP 1.2 terms then we have to answer
MarkJ's questions?
Noah: we may have to. Independent of that, the authors can cast it in SOAP
1.2 terms.
DavidF: question to authors - do you want the work (that Noah mentioned -
 recasting it terms of SOAP 1.2) to be part of what WG does?
Gudge: yes.
MarkN: yes.
Noah: one of the reason for this is - there are some things that are ambiguous
 because of the presentation. That is why I am suggesting that we do this
 exercise atleast on the difficult/controversial parts.
DavidF: the coauthors want the ambiguities to be worked out in the WG.
Noah: if there is a consensus on the important issues then it would be the
best way to proceed.
DavidF: we need to recast the proposal in SOAP 1.2 terms. We should also
have a meta-req - it use the mechanisms defined in SOAP 1.2. That is something
that we should agree on.
<+1 from MarkJ>

<action to generate text for such a requirement to Noah>

MarkJ: we are blocked on R6 (+ a few more). We stopped because we were not sure
 if it made sense to talk about parts. I would think we should go through the
 requirements, and see if we would block on ambiguities. Fundamentally, we
 have to do what Noah says.

DavidF: the most critical question is - what exactly is the binding model
and casting it in SOAP 1.2
MarcH: there is discussion going on in the ML that is quite important. It
is the nature of how this thing sets in the infoset. Whether an include
element appears in the infoset or it does not.
Gudge: it is the latter.
MarcH: that seems to be problematic. This means that performance adv. go
away. Especially for signing and things like that. It makes more sense to make
 include as part of infoset. I don't think everything has to be expanded as
 XML.
Noah: my understanding is much closer to Gudge's, but the doc is not framed
in a way that make this easy to understand. 2 levels - at one level it is
all characters (include does not belong). At the 2nd level - here are set of
 implementation tricks that can be used so that the char conversion are
never done (except for things like security). What MarcH is arguing is -
against PASWA.
March: I think I bought a differnt version of PASWA.
DavidF: looks like a number of recasting activity - infoset, binding. What
is the best way to move forward - take the input doc and reconvene the ATF
and have them come up with a new doc (or even within the WG)? Have people
 proposal for large scale changes? Can we identify particular types of
 proposal that we should be generating to make changes to the doc?
JohnI : one thought - rather than changing the whole doc, can we capture
the concerns in a 'table of content' and use that as a template.
Gudge: I pretty much agree what Noah says. We outline that there is nothing
to stop an impl. to do some facy stuff to enhance performance by not doing
 character conversion.
DavidF: we should start discussion on the ML. Or to convene a small group
to come up with a proposal.
Gudge: before we have used TF when the group has lot of things to focus on,
it does not seems like there is not a lot to focus on.
DavidF: 3 ways: 1) rewrite - get someone/group to write it 2) mechanism of
 generating a TOC, 3) let the discussions continue longer and see if they
 coalase and revisit it later.
Gudge: +1 to option (3)
Noah: I don't like just (2).
DavidF: we should continue email discussion and get a common understanding.
If people figure there are obvious changes to the doc, then that should be
 documented.

<meeting adjourned>