W3C XML Protocol Working Group teleconference, 1 August 2001

1. Roll call, scribes for minutes/action items (12.00 + 5)

Present 38/32 Excused Regrets Absent

2. Agenda review, and AOB (12.05 + 5)


agenda was reviewed by David. He discussed in a little detail agenda items
5, 6, and 7
Noah asked about room for MIT f2f - it was posted to email - David will
reforward to list
David asked about hosting for November f2f - still being checked on

NO AOB items

3. Approval of minutes from July 25 [1] telcon (12.10 + 5)

4. Review action items, see [2] (12.15 + 20)


Paul Cotton to send email on issue 30 by July 11
     Not yet done

2001/07/25: GlenD & Noah
     Prepare draft text for the spec clarifying what the spec does/does not
     mandate for mU/final recipient errors, and point to types of mechanism
     that could generate such error
     not yet done - will be done by end of business Monday 8/6 - possibly
earlier

2001/07/25: GlenD
     Propose a mustHappen mechanism (in loose terms, i.e. not as tight as
     specification language)
     doesn't remember exact context - already been one proposed by Noah -
Glen will evaluate Noah's prior proposal to see if it is usable -

Noah mentioned that it might not be in proper form - promised by end of
business Monday

2001/07/25: Editors
     Propose new wording that will fix the current overlap between sections
     2 and 4.* (this overlap is currently called out as ed's notes in the
     spec)
     done on Monday by Marc Hadley - David F will look into putting this on
an upcoming telcom


Change on issue 107 - change not needed because language is now gone  -
email will be sent to Eric Jenkins who proposed the clarification  -

Marc Hadley will do this

2001/07/25: Eric Jenkins
     Proposal for resolution of differences between "SOAP application" and
     "SOAP node" (Deadline: next week)
     Eric sent email saying he hadn't done yet - Eric not on call - will do
by next weeks call

2001/07/25: Chris Ferris
     Draft spec language for handling application-defined attributes vis a
     vis the infoset description, due 27 July
     Chris drafting now - will have it done by end of day today

5. The RPCTF wants the WG to respond to a proposal that RPC be split off

from a "core" spec [3]. (12.35 + 15)
The mailing list responses to this proposal have been overwhelmingly
positive, the main points of discussion being what else to split out of the
current spec. The discussions have revealed several facets that appear to
be part of the motivations for a split:
-- distinctions between "core", "extension", "application"
-- distinction between what is required and what is optional in the
implementation of a SOAP 1.2 conformant processor
-- ambiguity of "convention", "rules" (in contrast to must, should, etc)

>From the discussions, there appear to be two proposals to consider:
(i) Split the current spec into >2 documents, specifically a "core" spec,
and a number of other "extensions" (loosely defined) specs. This approach
has been criticized as leading to an unwieldy number of documents.
(ii) Split the current spec into 2 documents, specifically a "core" spec
and an "extensions" (loosely defined) spec including RPC, Encoding,
Transport Binding. The "core" spec describes what a SOAP 1.2 processor must
implement, and the "extensions" spec describes what a SOAP 1.2 processor
may implement.
If the WG can decide on one of these (or another proposal), we will do so,
otherwise we stay with the status quo.

David F reviewed the proposal and its motivation. reviewed the 2 basic
proposals that came out of discussions that are listed above - asked for

groups opinion

Paul C mentioned that pulling RPC out of main spec might have a negative
impact. GLen D brought up issues of other groups and other work that

standardize different ways of doing thing on top of core - we need to start
thinking about how this should be done
Henrik - pointed out we are aiming to have a modular design - but we have
to be careful that what is in the core is usable - and that in order

to do this the wg may need to define more than the core - having hooks and
orthogonal things is different than saying the work should be split

off

Paul C wondered if its just not an editorial issue on how doc is written -
could be cleared that RPC is not mandatory - that it could all be in

one doc if the text were clear on whats mandatory

Noah - can see it both ways - brought up example of Schema - some people
only needed to look at datatypes - however XMLP is not as large - may

not be needed here - has slight leaning toward splitting - a reason for
splitting could be if things were on separate schedules

Paul C responded - separate schedules was a slippery slope - might make
people feel some work didn't need to be done by WG

Frank DeRose -  brought up issues of section 5 and 7 and work of RPC
subgroup - dependencies between section 5 and 7 - if section 5 is split

out - section 7 might need to be

Glen - presupposition that section 5 would be split - agreed with Paul C
that it was an issue of how the doc was written

Dana - disservice if logically independent things are included in core doc
- could mean there would be multiple documents

Chuck - suggested everything is same doc and identifying things with
feature ids- core could be labeled by feature id to indicate what is

mandatory and what was in each package

John I - important to show layering - that there is a core that can be used
for both RPC and other things to reduce perception that core is RPC

- needs some separation - prefers splitting into separate doc for RPC and
transport bindings

David F - wg seems to be agreeing that split should be made cleanly and
correctly to clarify some misperceptions - the issue is how we do it -

single doc or multiple docs

Took a non binding straw poll - one doc with well delineated sections vs 2
separate documents, and publication of the 2 documents is ganged -

13 for single document
17 for 2 documents
1 abstain

No-one said they could not live with either option.

mention was made that even with 2 docs the table with feature ids would be
helpful

Paul C doesn't think 2 docs are a good idea - more than 2 definitely bad -
some agreement with this sentiment

Noah - doesn't find this persuasive - splitting emphasized that by
splitting you are saying core stands on its own and can be used in a wide

array of uses - some users will never need other documents - also could see
Paul C's side of argument

Paul D - need to tackle whats core and whats optional - then we can figure
out how to document it - David F said that discuss must happen

either way

David F summarized - slight preponderance for 2 docs - noone who can not
live with 2 docs - propose we instruct editors to divide spec into 2

docs - with understanding they will be published simultaneously and kept in
sync - no objections to this so editors were instructed to do the

split
- we will have to deal with issues of boilerplate issues and names of docs

Noah - mentioned dependence of chapter 5 is dependent on chapter 5 - should
they both become the split off point - another point of view that

nothing prevents using chapter 5 for non rpc - so it could be part of split
off - this needs to be dealt with - David said 5 and 7 go in new

part - also chapter 6 which is HTTP binding  - this raised issues of how
many docs should be split off -did HTTP binding belong with RPC, core,

or someplace else

Noah - what is conceptual title for part 2 - RPC or everything that is not
core - Marc Hadley believed all non core stuff should be in part 2

perhaps RPC could be expressed in an abstact way so it could stay in core

David F - we have agreed in principle to split - editors will do the split
then we will have something to look at - Henrik -  perhaps we should

wait for output of task groups before doing the split - David F - some new
questions on how split was made - do people feel we should do split

now or postpone it

Mark Jones - real issue is capability to cleaning do the split - not
whether we have multiple docs but conceptually can it be split even if

there is only one document

David F - some people made other arguments for split

Noah - not sure whether we are ready yet to decide on number of documents
till we understand all of the issues involved

John I - problem is there are a whole number of issue for different
audiences  - we need a proposal - editing team should look at whats

emerging from taskforces and make a proposal for how material should be
presented in a coherent way to different audiences  - there is also

issue of primer -  general agreement with this

GLen D - community is going to want guidance on how to add their own
extensions

Modified decision - editors should come up with proposal that also includes
what the content should be and how it is presented - editors should

come up with proposal for documentation structure - what documents there
will be how they will be organized, etc - Henrik didn't understand

what this meant - John I responded - this essentially involved deciding on
the table of contents for each document that was decided on - that

this also included seeing what editors felt was a suitable breakdown of
documents that included the work the task forces were doing as best it

could be determined at the time - general agreement on this - editors were
instructed to proceed

6. Issues 78/16 (12.50 + 30)

The basic issue of 78 is how to identify the request or response element in
the body of a message; the request/response element can be one of several
child elements of <body>. See email [4] that provides a summary list of the
references to the current proposals and background material.

Frank DeRose gave a review of issue 78 , its relation to issue 16 and
proposed resolution . Issue is how do you know what is the RPC element

and what is the multiref element - it was noted one could use root element
on rpc element to indicate it was the serialization root. RPC

taskforce decided to punt on root element and add a new (optional)
attribute called start attribute on the body element which would point at

the element that was the start of processing element -would mean entire
body would not have to be parsed to find start and would be useful with

things other than RPC - this is the current proposal - create new RPC
namespace , create new start element - namespace might be useful to add

other RPC things in the future

Paul D - if start attribute was useful outside of RPC it should be in
global namespace.

Henrik - not sure of benefit of this over root element - Frank said it
avoids needing to parse entire body to find start point

Paul C - questioned how much of an advantage this was - Frank mentioned
other issues involved - for example use of root implies a dependency

between section 5 and 7 - would use of start attribute avoid this
dependency. Frank is just trying to point out issues - not necessarily

advocating this change -

Noah - chapter5 introduces abstract type of struct - chapter 7 is only
dependent on this type - suggests separating notion of datamodel which

is a directed graph from the way it is serialized and that the spec
provides one encoding but others are possible - Jack wants there to be only

one way of how to do RPC and it should just use one encoding. Frank D - we
have been talking of rewriting spec in terms of Infoset - how would

this be done with Noah's proposal - Noah claims data model is already at a
level above xml and that to do this using Infoset would be to

express things in terms of element and attribute information items

Dana - is this necessary - will people use this high level data model -

Paul C - not hearing concerns about backward incompatibility for people
using section 5 and 7 together - Frank says yes they are aware of this

issue  Paul C asking that current usage be taken into the decision process
on this - Frank mentioned there is also another proposed solution to

this which is a rewrite of section 5.6 which clarifies use of root and
keeps section 5 dependent on section 7 - Paul asked if a middle ground

was considered which was to state that if you do RPC with encoding defined
use root - with other encodings strongly consider the start

attribute

David F  - in terms of compatibility he noted start attribute was optional
and if absent there was some ordering implied which was the one that

was closest to current practice.

Paul C - this is good

Jack - will postpone his comment to list

Noah - Paul C's proposed solution is the preferred one in his view

David F - how to proceed on discussion on this issue - no consensus reached
- will have to continue discussion on email  - Frank will take up

the Paul C solution offline with Noah and they will come up with a proposal
- will also summarize the discussions we have been having and will

post it to dist-app

7. Review Primer Proposal [5] (1.20 + 10)


Needleman had to leave the call and Nilo took over as scribe

++++++++++++++++++++++++++++++++++++++++++
Meeting minutes from 4:30 onwards on 8/1/01 recorded by Nilo Mitra

David F asked wg whether it could continue discussing Primer after
scheduled end of call: 13 people left on the call, none objected to

continued discussion

David asked for reactions to the Primer proposal from Nilo et al which was
posted to the list.

Chuck C: primer is a very important deliverable. Should be a standard W3C
output. Should be a best practices document. O'reilly has an example,

which we could use as a model.

Paul Cotton: Support some of the things in David F's amended proposal.
Scale it way back. Don't waste WGs time on design decisions, best

practices,...WGs are better off working on early implementations

Hugo: The W3C QA activity also includes outreach, making sure that specs
are well understood...

Nilo: Design decisions could be found quite easily by going through the
archives. Burden would be on the editors. Also, there is a need for

SOAP to be "sold" to other communities, like the large wireless standards
groups who are planning on using other distributed technologies.

Doug: Does the spec need a primer because there is a deficiency?

Mark: if you have primer you can make the spec more concise. But you don't
need a book.

Jack: Primer would help, and make the spec more concise.

Mario: Primer would be a good idea. [ Something about schemas which I
missed ]

Henrik: The editors have tried very hard to make the SOAP spec less
confusing. Please point out remaining confusing parts to the editors so the

text can be improved. Also, size of SOAp spec compared to schema is
drastically different. SOAp spec is relatively light weight.

Herve: Would be a waste of time.

Paul D: Like the idea of a primer, but keep it focussed on use cases.

Highland: Like the idea of a primer, but limit the scope.

Dave F: In summary: a few people are concerned about resources, some think
proposal is too big, send it back to the originators to come up with

something more reasonable.

Nilo: Dave F's email on the proposal contains a well-defined subset. That
could be the starting point.

Paul C: Suggests putting effort into the use cases and achieving
interoperability.

Hugo: primer will help.

Paul C: Not sure if this kind of documentation will help with
interoperability.

Chuck C: Not doing it would relegate to outside W3C.

Paul C: Yes, give it to professional technical writers. W3C should
concentrate on technical work.

Chuck: Communicating clearly is part of W3C.

Nilo: Let's use David's email as it has the right scope.

paul C: removing exmaples form spec to primer is not a good idea. For
section 5, this is a bad idea.

Hugo: sec 5 has less examples.

Dave F: The new proposal should include how to handle examples that are
currently in the spec.

Dave F asked Nilo to provide by Friday a proposal back to the group which
includes the 4 points from David's email and how to deal with

examples. Nilo accepted.

Meeting ended at about 1:45pm PDT

References.
[1] http://www.w3.org/2000/xp/Group/1/07/25-minutes
[2] http://www.w3.org/2000/xp/Group/Admin/#pending
[3] http://lists.w3.org/Archives/Public/xml-dist-app/2001Jul/0272.html
[4] http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2001Jul/0157.html
[5] http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2001Jul/0120.html
[6] http://www.w3.org/2000/xp/Group/xmlp-issues.html#x109
[7] http://lists.w3.org/Archives/Public/xml-dist-app/2001Jul/0125.html