W3C XML Protocol Working Group teleconference, 7 November 2001

Minutes for XML Protocol WG Telecon 7 November, 2001 Present 32/26 Excused Regrets Absent

2. AOB

 - none

3. Review of the agenda.

 - minutes approved as posted

4. Action items

5. Status reports


- f2f meeting
Chris: update on local details sent to local group - video con on  all
three days is available. want to keep number of video sites to  a minimum.
would like to know who are the video site hosts
Herve: Canon should be able to host a video site although they might not
allow others to attend
Chris: please let us know so we can test the video link
DavidF: it is critical that multiple people can attend a video site in
western europe
Herve will find out  whether this is indeed ok
StuartW: Hewlett-Packard has video facilities in Bristol (England), he is
attending the f2f in Boston but can look into Bristol as an alternative
DavidF: prefers Stuart to wait to see what Herve comes up with by end of
week

- Primer
Nilo: no news to report

- TBTF
No report

- Editors
No report

- ETF
PaulC: ETF has been working on issue resolution, namely agenda item 6 on
issue 1, and it is working on text to close issue 18
Hugo: received list of issues reassigned to editors from jacek, hugo will
be co-ordinating that list

- Conformance
Hugo/Oisin: nothing to report, no constribution of tests, still  need the
official ok from microsoft for use of some tests.
Hugo: The document needs to be updated, not sure how to get more
contributions
Henrik: is it true you still lack something from Microsoft?
Hugo: has sent email (cc  to PaulC and Henrik), awaiting official email
from Microsoft
PaulC: I will sort this out
DavidF: how many tests are there, e.g. are we half the way there?
Hugo: we are not very far, if we integrate soapbuilders' tests, we are
maybe a quarter to third, but definitely not more than a half
PaulC: we need more tests!
DavidF: we could assign WG members to generate tests for sections of the
spec
Hugo: that would be great
DavidF: in a previous telcon, someone noted that generating tests is a good
way to understand the spec, although this cuts both ways
PaulC: (tongue in cheek) given xml hack's commentes, need broad
contributions,  those who work for larges companies shouldn't have to
produce the tests (???). In schema there is a race going on to generate
tests, e.g. Microsoft donated 4500 tests. People who have implementations
need to bring some tests to the table.
DavidF: is anyone willing to volunteer to generate tests?
Silence.
PaulC: Suggest allocating time at the f2f to go into working groups and
hammer out tests as a way to move forward
DavidF: That's a good suggestion

- Usage scenarios
JohnI: received no comments on the posted version, I am planning to work
more on them. I am hoping to create another revision in time for next weeks
telcon. I would appreciate someone taking a look at them.

- SOAP + Attachments
DavidF: the assumption for this work is that we want to find a venue for
working on S+A or S+A-like mechanism with the criteria that it happens
relatively quickly, and some guarantee that it will indded happen. I have
spent time at the AC meeting talking to people about making this happen.
The current plan of action is to write a new charter for the next rev of
the XMLP WG that will include a line item which includes a S+A mechanism. I
need to run this by the XML CG many of whom are here at the AC meeting.
They need to know such a proposal is coming. I need to put it on the XML CG
agenda. With the people I have spoken to here, there appears to be
agreement that this is a viable way forward.
Chris: are you suggesting that the only venue for S+A is the next rev of
the XMLP WG
David: yes. I believe this is the fastest way to get it done outside this
iteration of the WG. Does this answer your question?
Chris: yes, but I am not happy
Anish: how about a proposal to make a non-normative reference  to S+A and
say that this is one of the ways to package binary data. Is this still on
the table?
David: what does this mean? It is no different to the submitted note. If we
get a new charter done soon, we can point to that as being en route and
that is a clear enough signal.
Chris: my concern is not beginning work on it until late, when would that
be?
David: we have a f2f in February that according to our schedule is between
Last Call and Proposed Rec.
MarcH: are we still on track for issuing last call after f2f? We have lots
of issues.
David: I am also worried about the number of issues remianing.
MarcH: any slippage in schedule could cause S+A to be worked on much much
later
David: yes, I am afraid of slipping the schedule, I think this is a likely
outcome
Noah: there are two big issues on table, (i) what is the role of
technologies like S+A and how do we deal with them, and then (ii) how do we
get the core work in the charter done. On the one hand it is disappointing
to delay S+A more than necessary, but if we are already over our heads,then
the best thing for us to do is to get on with the core work we need to do
for Last Call. I have no objection to people working on it, but the ante is
going up. Should only work on this on the side.
PaulC: I suggest we take this to email and get on and close some issues
David: I have noted the concerns, please continue this discussion as need
be in email

6. ETF proposal for escaping illegal chacters

David: ETF has proposed an algorithm to map applicaiton defined names to
valid XML names, the question on the table is whether this is acceptable to
the WG. Is there any discussion?
PaulC: this algorithm is based on material from an ISO draft. Asir has done
a good job factoring out the SQL specific terms, but he made one change to
the algorithm. I recommend moving forward with his alg, subject to taking
his proposed change back to the ISO people because we don't want any
gratuitous differences. I should note that the ISO algorithm is used by a
number of Microsoft products like Word, etc. I propose the algorithm get
adopted subject to liaison with ISO. The specific difference is that the
ISO algorithm is only XML 1.0, Asir uses XML 1.1/namespaces. There is
probably no impact, but I'd like to take the algorithm back to ISO and
check that its ok. I will take action item to double check it is indeed ok.
David: point of clarification - the algorithm will be put inline in our
spec and we will say that it is derived from an ISO working draft
PaulC: yes, there is a reference to the ISO document in Asir's work, the
ISO algorithm is a work in progress hence we use it by direct inclusion
rather than reference, this is also easier for our readers without a SQL
background
Henrik: will the liaison continue so that there is no fork?
PaulC: yes, I will provide this liason
David: once the algorithm is inline, then surely we don't need to track the
ISO version?
PaulC: if it changes in the ISO forum becuase there is a mistake, then we
would need to know
David: so tracking should occur over the long term
StuartW: what is the cycle time for first cut response?
PaulC: there is a 4 hour ISO call next week, I will put it in front of
them, although it may not get full attention. The group is SQLX. I am
confident that we can get feedback in a reasonable time.
Hugo: we need some examples, the algorithm is hairy!
PaulC: we can provide these examples to the editors
DavidF: the proposal is to adopt the proposal from ETF and to consider the
issue closed unless we hear back negatively from the ISO group. PaulC will
be taking an action to obtain feedback from the ISO group, and take on the
long-term tracking. Are there any objections to this proposal?
No objections raised. Proposal passes.
Action on PaulC to email Eric Smith (issue originator) and xmlp-comment

7. Issue 101

David: there should have been an action on me to corral all of the threads
regarding issue 101, but I didn't get to do this because of  travel so we
must figure out the issue on this call instead.
David: The issue - as written - concerns the special status of the Body.
There has been lots of email on this subject, but how many issues actually
are there? At least one aspect of the issue is considered editorial so need
to find out which issue(s) are editorial and which involve more serioius
design. Is there anyone who believes they can identify an issue out of the
original 101 issue and start the discussion?
Noah: should we relate such issues to existing numbered issues, or
potential new issues?
David: if issue 101 can be tied to existing that's good ....
Noah: I can identify issues, but I can't relate them to existing ones
David: that is a good enough start
Noah: the text in the spec states that the body is syntactic sugar for a
header, so we need to know if there is indeed a difference. There may be a
difference of intent. Lexically, multiple body entries are allowed, but we
need to clarify with regard blocks what has to be understood (in the sense
of mustUnderstand [mU]) and processed. The body must be one clear unit of
work. Streaming also presents issues. Headers may be short, whereas a body
may be long because that is the main unit of work. There is a  question of
how you indicate that you have not understood the intent of one or more
things in the body. The implicit mU suggests an mU fault to some people,
others say some other fault should be generated.
Noah: the notion of bodies as syntactically sugared headers unifies the
processing model. If a processor doesn't understand body, then there's
nothing there which states that headers should or should not be processed.
If we say the body is  a header then ????

Noah and David attempt to summarise: 4.3.1 is the section in the spec
detailing the relationship between header/body block. Once we settle all
the other things we have to go back and make sure that this section
reflects what we mean.

1. is the body really a syntactically sugared header?

2. there is a question about what is processed as a block and how many
things can be processed in the body - some say one unit, other say
multiple. A combination of this and mU may make streaming more difficult.

3. if a body has children 'a' and 'b', does this imply two units of work,
or is 'a'  the unit of work and 'b' provides supporting data, or vice
versa?

4. how to indicate that a part of the body has not been understood

5. if body parts are separate, and not like normal header blocks, then we
have to look at the processing model and unify it

David: it seems that depending on how we answer any one question, something
else may crop up as an issue. Are there any more issues to be identified as
related to 101?

Dug: two things, (i) I am worried about implications for implementors of
header==body , and (ii) headers are our the extension mechanism, but
technically extensions can be placed in the body

Chris: another aspect that concerns me is whether the anon actor in the
header is the same thing that processes the body

Henrik and Dug: that's a different issue.

David determines that no-one has any more issues related to 101. He turns
discussion back to those points already raised.

Henrik: Dug has brought up the most straightforward answer; the body is
equivalent to a header *block*, it must be understood, and it is for the
end guy. This avoids the problem about faults; one must understand the body
block, and so a mU fault does not get raised. This is straightforward
because we have not seen a special use for blocks in the body --  ie
multiple units of work in the body -- we can do that using headers. If we
say the body is one block rather than a set of blocks the number of issues
is reduced to just one.
David: please restate this as a proposal
Henrik: the body is the same as a header block, and with regard
intent/boxcarring we need to express how the body is used, we need more
guidelines.
David: I would like feedback from Dug and Noah on this because what Henrik
is saying may be a proposal to resolve the issues.
Noah: some aspects of this are good, but there is part of it that doesn't
click. If we say it is the body element *itself* that you have to
understand there is no mU fault, but  this seems silly. Let's say there is
a purchase order in the body and I receive the message but I don't
understand purchase order. What are the
processing model rules? We understand body, and headers, so we start
processing headers but then find out we don't understand purchase order.
Nuts! I think the mU is on the *purchase order* which is the first  child
of the body. It is vital that no work gets done until the headers and the
body are ready for understanding.
David and Noah attempt to summarise:
 2. With regard to understanding in the mU sense, it is the contents of the
headers that have to be understood. We have to cover understanding of  the
body content.
 1. Putting mU on body is asymmetric. We have to put it on envelope and
everything ????

Henrik: it is a general client fault when there is something within a block
that is not proceesed. If I know about it then I have to start processing
it. There may be stuff in the content of the block that may call a fault.
Nested faults let you say "this is a client fault" and "this is a purchase
order fault"
Henrik: mU says you have to understand the block, not that you will be able
to process it successfully, as in the purchase order example you gave.
Noah: what if weather service ????

????: you could have processed headers when you find out that you don't do
the body

Dug: I like what Henrik said about the body being a single computational
unit, maybe we should remove implicit mU on body. Regarding not being able
to process the body after starting on the headers...headers are used for
extending the body, make sure that you understand all of the headers then
you can go
look at the body.

Noah: chapter 2 states that all headers must be checked for mU headers
entries before any other processing, but having done that the processor is
free to process headers and body in any order unless there is a header that
imposes ordering

Dug: I got lost there at the end
Noah: to paraphrase "What kind of fault you generate is your business".
Dug: I think that is the proposal being made ....
Noah: I can live with it...
PaulC: we should put strawman on the table to see how this solves the
issues. It need to be written up.

WG expresses general understanding and agreement

Noah: I am a bit nervous about it but think can live with it

David: we will take this discussion to email. Action to Dug/Noah/Henrik to
craft the text for this proposal. Action to Oisin to get send the summaries
to Noah before he starts travelling.

8. issue 146

Stuart: the issue arose because of discussion beyond issue 140. In
particular, are the actor default actor, ultimate recipient synonymous? I
think they are but they evoke different things to different people.
Henrik: I think the question is not so much what the actor/destination
means but how much we have to say about whether a message physically stops
at that actor. In other words, who does what and how.
Stuart: I have seen message paths with 3 anon actors  which suggests the
anon actor is not the ultimate recipient
Henrik: looking at that scenario it could be right or wrong. There could be
intermediaries at a higher level, we think it end ????, but really could be
higher level intermediary
Stuart: where does the soap message end?
Noah: we need to clarify the text in places. It is not good to have mushy
notions about a endpoint but the message keeps going. Whichever node
decides to act as the anon actor is it. and the soap message path ends. If
we go in another direction then need to change the paragraph
Henrik: I am happy with this
Noah: if I have a header with anon and I process it, then can i pass it on?
The spec states that if you process anon actor header then that's it, you
can't relay it
Henrik: agrees.
Chris: back to issue 101; if body blocks are syntactic sugar for header
then with anon actor role then the body gets sucked out!
Dug: I need a use case. If a header is targetted at the anon actor, how
does the sender make a message...
Noah: this is the mustHappen question, and it was decided in Rennes (a f2f
meeting)
Dug: I don't think so, I  have to think about this.
Chris: if the ultimate recipient is the next, default and any actor
Dug: yes
Chris: an intermediary can't be the default
David: Noah, you were looking for a clarification on 2.5...
Noah: concern was that we would change the rules then we would really have
to re-work 2.5. but it does need a minor clarification -  nodes which
assume the role of anon actor must not relay the message
David: Dug is that ok?
Dug: yes, I would rather change the text, but if Henrik and Noah like it
the it is ok
Stuart: I make an editorial plea --  choose "default" or "anon" for the
actor and stick with it.
David: didn't we already decide to use only one term?
Stuart: we use "anon actor" in section 2, and "default actor"  in section 4
Hugo: We decided to use anonymous a few months back. The changelog of
the spec reads:
    20010615  JJM  Renamed default actor to anonymous actor for
                   now (to be consistent)
Noah: there are still some occurrences of "defualt" in the text

Action item on editors to ensure all "defaults" are changed to "anonymous"

MarcH: issue 146 is indistinguishable from 140
David: we should then record that in the issue description text
Hugo: I changed the issue text this afternoon
David: if someone proposes text for 146, we can decide to close it

Action item on Henrik to generate resolution text for 146

9. Issue 135

Hugo: there are 2 issues here. First, there is a piece of text in the spec
saying that processors must discard messages having the incorrect
namespace. The "must" used to be a "should", and although it had been
proposed to use "must", the decision had not actually been made. Second, a
message was sent to the list stating that it is inconsistent with the
versioning model to say that a soap app 'must' discard messages that have
incorrect namespaces, and it was proposed instead to point to the section
on versioning.
Henrik: did we talk about this already?
MarcH: if a message does not have the right namespace, it is not a soap
envelope
Stuart: in the list email, it suggests striking the tail of the sentence,
not a proposal
gudge: strike discard?
A few people said you cannot do that [ie substitute the correct ns]
Chris: I agree with getting rid of discard
Henrik: the right thing is to say that we must have the correct namespace
on a soap message. If  it has no ns then generate a versionmismatch fault
Chris: we could replace the word 'incorrect' in the text with 'unsupported'
which is more appropriate.
Henrik: what about "if you don't see this ns ...." and provide a reference
to the namespace in our spec
Dug: if we support an old namespace then do you support its processing
model
PaulC: isn't that out of scope?
Dug: versioning issues..
Henrik: special case for this - the 'other' namespace which is in the
versioning section
PaulC: do you want us to deal with this as part of a general versioning
issue?
Dug: yes, maybe, could live with it but feel weird about it
David: do we accept the following proposal?
 1. ratify the use of word 'must' in the spec
 2. say explicitly that if you encounter an ns other than (reference to our
namespace) then you send a version mismatch fault

Chris: I disagree - this means it can't process it - which is what Dug says
Henrik: no - you are not 1.1
Noah: new specs can almost always look after previous versions
PaulC: extensions are out of scope for the specification, but not for
implementations
MartinG: make sure the 1.1 processor gets in first!
Hugo: I posted an email detailing the different scenarios to
xml-dist-app:
http://lists.w3.org/Archives/Public/xml-dist-app/2001Oct/0213.html
Dug: OK, can live with it
David: Chris can you live this?
Chris: yes
David: are there any objections to closing issue 135 with the proposal just
described?
No objections were raised.

Action item on editors to make the change to the spec.
Action item on Hugo to send resolution text to xmlp-comment