W3C XML Protocol Working Group teleconference, 23 January 2002

Minutes of the XMLP WG telcon on 23 January, 2002.

1. Roll call

Present 27/22 Excused Regrets Absent

2. Agenda review, and AOB

AOB itme: FTF Hotel deadline extended to 1/31


3. Approval of January 16 telcon minutes

Minutes approved as posted without any changes.


4. Review action items

      Question from Paul Cotton:  where do we stand on charter extension?
      DF: he is preparing a draft. Paul C:  CG would like to know about it.
      AI maintainers to add an action item back to AI list.


5. Status reports

-- Primer Nilo:  has incorporated some comments from XMLP comments
-- Spec Hierarchical fault codes resolution added.   Mail sent on related
question for RPC fault codes...temporary solution in the spec.  Part 2:
href -> idref change made, array encoding changed, comments welcome.  Sent
out some requests for comments on rewrite of part 2.  Find links to editors
drafts on public page.
-- TBTF  There will be a second binding, tentatively in the primer, for
SMTP.  Paul Cotton expressed concerns that this should not delay
publication schedule, including to last call.  TBTF group will approach
David to reconsider whether to publish SMTP binding in primer, as a W3C
note, etc.
-- ETF
Jacek: apart from what's on today's agenda, the ETF made a decision to move
away from XML schema in the examples.  Decided to repost for further
discussion examples regarding missing data.
-- Conformance work: Hugo: goal is to incorporate stuff from last ftf, and
now that IPR issues cleared, from the soapbuilders tests.  Short of time,
not sure whether Oisin has time.  David F:  any volunteers?  No one
volunteered. Paul Cotton:  what about people who work for members but not
in the WG?  David F:  OK, send me one.  Anish volunteers for conformance
work.  Jeff Mischinsky volunteers as well.
-- Usage Scenarios
John Ibbotson:  latest were released as part of WD for comments.  None
received.  John is not aware of any outstanding to do's, except for some
editorial comments from colleagues at IBM. He is waiting for more comments
from others.


6. xmlp-comment proposal

MartinG has looked through the comments posted against our recent WDs and
he has proposals for how to deal with each one of them [3].

The recommendations are referred to as:
Non-issues (a) (b)* (c) (d)
General (a) (b)
Part 0 (a) (b)
Part 2 (a) (b)

JacekK has raised a comment against 'non-issue (b)', see [12], in which he
claims the text in the WD is present in error and he proposes a different
resolution. Do we accept MartinsG's recommendations incorporating JacekK's

Yes...accepted without any dissent. Implementation of this decision goes on
editors' to-do list.


7. Issue 170, ref'ing data that may be stripped from a message

What is the spec language that describes when to generate a fault given the
existence of a non-dereferencable IDREF? The discussion revolves around
MUST, SHOULD and MAY. Jacek has proposed text that includes "MUST" [5].
There has been discussion around this proposal that appears to partly hinge
on the interpretation of the phrase ".... a reference to a missing ID is
found, the application MUST generate a fault ....", and whether this
implies that a processor is obligated to look for such references.

Long debate about MUST/SHOULD etc.   Chair takes informal poll on:

"When SOAP Encoding data is being dereferenced and a reference
to a missing ID is found, the application (strikethrough: MUST )SHOULD
generate a fault
with faultcode env:Sender and subcode enc:MissingID."

9 in favor and 1 (Henrik) expresses concern that SHOULD is strong in its
implications.  Using it in this way may undermine interoperability in that
some will presume that well-written implementations WILL generate the
fault, and won't do the right thing when the fault isn't there.  However,
Henrik can live with "SHOULD".

Formal proposal:  to close the issue with the revised text as above.  No
objections, issue closed.

Mike Champion will be exploring the question further, preparing an email,
which MAY result in related questions being (re)opened.


8. Issue 168, type of referenced data

The ETF proposes to keep the status quo for this issue, i.e. to require
that every value is typed [7]. Does the WG accept this receommendation?

Jacek:  the issue went away, given that we now use ID/IDREF.  Noah:  but
there's a question about whether the status quo does type every node?  What
if there's no xsi:type and no validation?  After some discussion, there
seems to be a agreement that we need to say something about this case.

David F: The ETF need to propose text to cover this, as part of the
resolution of 168 (which remains open), though with an understanding that
all are agreed that the original question regarding external data is


9. Issue 137, intermediaries relaying SOAP messages without modifying them

[8] (1.10 + 20)
The issue concerns applications/intermediaries that may need to modify
blocks that are not targetted at them. The issue's originator provides a
number of alternatives [8]:
i) 'disallow'
ii) 'allow'
iii) 'soften to SHOULD'
iv) 'new mechanism'
Can we pick one of these alternatives?
Discussion of this issue assumes it is indeed a dupe of #175 [9]. Issue 137
refers to what is now the last paragraph of section 2.6 [10] (not the Note

Henrik proposes:  default is that intermediaries can do just about anything
to a message, headers can be used to tighten the rules.
Noah:  I like the idea, but I think the default has to be the opposite.  If
a sender does not give permission for the message to be mangled, it should
go through intact.  Otherwise, how does SOAP help you at all?  Any message
you send could be changed in arbitrary ways (e.g. change the amount of an
update on a bank account.)

Discussion on which should be the default.

David F: We are out of time, we will take the discussion to email and
revisit it next week.