W3C XML Protocol Working Group teleconference, 22 August 2001

1. Roll call, scribes for minutes/action items

Present 30/27 Excused Regrets Absent

2. Agenda review, and AOB


No changes requested, no AOB items.

	

3. Approval of minutes from Aug 15 telcon


Approved without dissent.

        

4. Review action items


2001/08/01: Frank DeRose
     Send summary of the discussions on the proposals and clarification
     (including the "kludge" proposal) re. issue 78 to xml-dist-app.
     Frank: remains open...we'll talk about it when we get to RPC task
     force report.
2001/08/15: Editors
     Come up with naming proposals for two titles and reasoning behind
     these proposals by Monday.
     Accepted suggestion to discuss this later in the call.
2001/08/15: Editors
     Propose wording for updated paragraph regarding discussion in agenda
     item 6
     Any other editors who know whether this was done.  Henrik:  not quite
     sure.  Chair:  please check during the call (later decided to leave it
     open pending check with Marc).

        

5. Reports (12.30 + 20)


-- Transport binding task force
Glen Daniels:
Recap:  we're trying to sort out several proposals on how to do the binding
framework.  One came from Noah, Highland, Glen Daniels meeting.  Others
from Henrik and Stuart Williams.  We've spent a lot of time trying to sort
out where differences are real, getting terminology consistent across the
proposals, etc.  Some proposals work top (application) down, others work
bottom (transport) up.  There are differences on what should be viewed as
"a binding".  The NHD proposal, on its surface, uses it for things that
drive transports.  Henrik uses it for broader concepts including MIME,
etc., that may not have to do with the envelope or transport.  We
tentatively agreed to use the term at least in the former sense, which is
the area of overlap.  We're now looking for (resolution of) the framework
in which to describe and compose these things.  One model (Henrik)
emphasizes nesting, while the other suggests that we don't have to say much
in our spec about how other layered specs (bindings, modules, etc.) would
compose.

Proposal text is needed in time for ftf.

-- Editors, names for documents
Action item:  need names for two parts of the document.  Also, expecting
group feedback on new structure for the docs.  Jean Jacques:  proposal:
Call part 1 "SOAP 1.2: Messaging Framework" and part 2 "SOAP 1.2:
Adjuncts".  Previous proposal was something like "core" and "extension"..
Trying to capture that part 2 will still usually be implemented;  felt that
"core" suggested that part 2 might be too optional.  Henrik: we haven't
decided what is mandatory or optional.  JJ:  Yes, but we want to allow for
requiring part 2.

Discussion:  Generally positive reactions on Part 1, some concerns on part
2.  Editors asked to try again on part 2.

Discussion of documentation structure, as opposed to title:  editors have
seen no feedback.

Editors confirm that they will produce two documents (parts 1 and 2) in
time for ftf.

Third action item above on application defined attributes:  decided to
leave it open...need to check with Marc.

-- RPC task force
Frank: covered 2 things in last call.
1) Proposal from Jack to resolve issues 16 and 113 using a <rpc:result>
element.  For non-void return type:  If null return value, two
possibilities: <rpc:result csi:nil=true'/> or just leave out the
<rpc:result>.  Choice is because section 5 item 9 which allows both forms
in a struct.  For void return type, just leave out the <rpc:result/>.
Mailing list comment:  if you allow all of these, you can't distinguish the
two cases in which the <rpc:result/> missing.  Mailing list comments
therefore request requiring xsi:nil in case 1.  Issue has lots of history
in the WG.  Not clear what WG will want to do.  Some discussion of
global/local scoping.

Glen Daniels: have you checked w/soapbuilders on nil? ...no clear
response...  Glen says Andrew Layman reported a preference to do it by
leaving out the accessor.  Graham Glass reported to have perhaps disagreed.
Glen and Frank say they agree.

2)  Proposal to recast section 5 to make distinction between data model and
encoding clearer.  Henrik to give preliminary text to Frank for flesh out.
Hasn't happened yet.

The task for is committed to providing proposal text in time for ftf.

        

6. Review of "mustHappen" proposal [3] (12.50 + 5)

The proposal's author recommends that the WG _not_ take on this piece of
work, do we accept his recommendation?

Proposal to do nothing is accepted.   Reason (Noah): we spent time in
Dinard and tuned up our basic mustUnderstand extension mechanism.
mustUnderstand is now sufficiently robust that mustHappen can be considered
as an ordinary extension.  We therefore are recommending that dependency
proposals such as mustHappen be deferred, and not included in either of the
two parts of the SOAP spec.  More background and details in [3].

        

7. Review of SOAP Application definition [4] (12.55 + 10)

There has been little response to the proposals, a couple of people did
respond postively to "Techy Defn #1". Which definition do we accept?

Henrik: prefers either status quo or non-techy defn.  Glen Daniels:  Agree
with Henrik.

Discussion (not all minuted);

Proposed Conclusion:  action item to editors and Eric Jenkins to craft a
definition based primarily on the first sentence of techy defn #1.  Henrik
says "no", implies some inappropriate things about layering.

Proposed conclusion (Noah):  see with the tranport binding TF comes up with
and do something that builds on that.

Chris Ferris:  I preferred the first one the Henrik didn't like.

Action to Chris:  come up with another definition, keeping in mind the
feedback from this call.   To be reviewed by WG prior to adoption.  Eric
Jenkins option to work with Chris.

[Vidur, Chris Ferris and Mark Nottingham acknowledge having joined the
call]

        

8. Proposal for response to XML Schema WG on base64 encoding. (1.05 + 5)

See emails [5] and [6] for background. Note also the clarification that "="
is only allowed at the end of the datastream as padding. We previously
tasked Martin Gudgin to make a proposal for XMLP's response to the XML
Schema WG. His recommendation is.
1. We do not have an opinion on whether Schema should enforce that all
base64 encodings must be a multiple of 4 characters padded with '=', unless
it can be determined that most implementations enforce the 4 character
multiple in which case Schema should enforce it as well.
2. We do not have an opinion on a canonical form.
Does the WG accept this recommendation?

Postpone until Martin Gudgin can participate.

        

9. Evaluation of new section 7.3 (RPC Faultcodes) [7] proposed by RPCTF and

Editors as resolution to issue 45 (1.10 + 10)

Amendment accepted:  item #1 (see [7]) on soap-env:server should be changed
to refer to section 4.4.1 which describes the use of the same fault in
non-RPC scenarious.

Action item:  Jean-Jacques and Henrik to take to email a concern on rule #5
relating to failure models of procedures, etc.  Target: end of day Monday,
France time.

        

10. Chair's outline of the September f2f meeting, questions (1.20 + 10)


FTF 9/11-9/13
Agenda is due out end of day this coming Monday.  Preliminary agenda posted
yesterday.  Comments to the chair by end of this week.  Registration closes
9/31.

Current plan:
* Resolve issues -- please respond by end if this week if you received a
query from David
* There will be proposals from TBTF and RPCTF
* Documents:  we'll have proposed split documents for review.
* Start "new" activities, including some previously set aside:  (1) usage
scenarios (2) conformance (3) encoding.


References.
[1] http://www.w3.org/2000/xp/Group/1/08/15-minutes
[2] http://www.w3.org/2000/xp/Group/Admin/#pending
[3] http://lists.w3.org/Archives/Public/xml-dist-app/2001Aug/0103.html
[4] http://lists.w3.org/Archives/Public/xml-dist-app/2001Aug/0070.html
[5] http://lists.w3.org/Archives/Public/xml-dist-app/2001Jul/0104.html
[6] http://lists.w3.org/Archives/Public/xml-dist-app/2001Jul/0323.html
[7] http://www.w3.org/2000/xp/Group/1/06/01/soap-02-infoset.html#rpcfaults
[8] http://www.w3.org/2000/xp/Group/xmlp-issues.html#x45