W3C XML Protocol Working Group teleconference, 12 D ecember 2001

Minutes of XML Protocol Working Group teleconference, December 12, 2001

1. Roll call

Present 27/21 Excused Regrets Absent

2. Agenda Review

No additional agenda items added.  John Ibbotson noted the Usage Scenarios
would be published as a WD (this was in David Fallside's agenda update).


3. Review of minutes

Fallside proposed that the approval of the F2F minutes be postponed until
next week.  The minutes still need to be cleaned up and completed.  No
objections from the WG on this proposal.

The minutes from the 12/5 XML Protocol Working Group teleconference were
approved as posted.


4. Review of Action Items

Henrik Nielsen requested that all action items be updated by Friday.  
Hugo noted that the list of issues are typically updated during the telcon


5. Status Reports

SOAP Version 1.2 Part 0: Primer - No status provided (Nilo Mitra joined
late).  Per Yves Lafon, there were minor edits made to the document to
make it compliant with publication rules; no content changes though.  
After changes are made, the document will be ready to go.

Parts 1 and 2.
Editors: Jean-Jacques said the HTML conversion has taken a week.

SOAP Version 1.2 Part 2: Adjuncts. Jean-Jacques: TBTF material has 
now been fully incorporated into Part 2, and converted to valid XML. 
Most comments on the TBTF text have also been incorporated, apart 
from a few exceptions, in particular adding labels to the arrows of the 
state transition diagram. 

David Fallside: You have not yet included my proposed rewrite of 
the new section 6! 

Jean-Jacques: Yes I have, but only in the XML version. I was waiting 
for prior WG approval before generating the HTML version! 

David Fallside: Oh!... There have only been positive comments on this 
text so far, so I propose that we accept this rewrite. 

No objection, so David's rewrite is accepted. 

In the background, Yves regenerates the HTML for Part 2 from 
the XML provided by Jean-Jacques. 

SOAP Version 1.2 Part 1: Messaging Framework. Marc Hadley: All 
issues resolutions and editorial changes have been incorporated. 

Per Fallside, actual publication decision is the subject of another agenda
item.  The group thanks Jean-Jacques Moreau for his tremendous efforts on
the HTML to XML conversions.

ETF - The group met briefly last week.  There was not a lot of work done
and attendance has been sparse.  There is a list of action items that the
ETF is working through to provide resolutions to issues.  Next call will
be Thursday, 13 December.

TBTF - The task force has not met since the F2F meeting.  We need to
restart this effort shortly.  There are a number of issues on its plate.

Conformance - Per Hugo, David Turner from Microsoft has provided legal
text such that we can use SOAPBuilders tests. Hugo needs to consult the
W3C Legal (or Joseph Reagle) to determine if the legal text is acceptable.

Usage Scenarios - Thanks to Yves Lafon for getting the scenarios converted
from Word to HTML particularly the tables.  Ibbotson is working on the
converting the HTML version of the document to XML and DTD.  Jean-Jacques
Moreau will send DTD used in the spec to Ibbotson.

Issues List - Per David Fallside, the issue list maintainers are backed
up.  When do they expect the issues list to be completed?  Yves Lafon will
update issues list by end of this week.  There was a question as to who is
the official issues list maintainer? Yves responded that he was doing it
since Hugo was busy.  Hugo indicated that he has no time to update it.


6. Evaluation of proposed responses [4][5] to Last Calls on XML Encryption

[23] and Exclusive Canonical XML [24].

There are no responses to the e-mail from David Orchard [4] that proposed
a repsponse. Per Orchard, a liaison group was formed as a result of his 3
July e-mail, but nothing happened.  Orchard said that there are two ways
of going forward (1) send the response as the opinion of one member, or
(2) send the response as WG's opinion and say nobody disagrees with it.
Orchard added that there appears to be great apathy on this issue.  Per
David Fallside, you can infer some information from the lack of response.
Fallside added that the XMLP WG was told at last week's telcon that we
were looking for an XMLP response for last call to the XML Encryption
group, and so it is fair that if nobody responded, this would go out as
the WG's response.

Action:  Orchard will combine the two responses (the other from Yen-Ling
Husband) as well as Paul Denning's comments.  Orchard will draft and post
the combined response today so the WG can see the final response.  
Fallside will send response to the XML Encryption Working Group on Friday,
assuming no WG pushback.


7. Publication.

Is there any objection to asking the W3C to publish Parts 0 [6], 1 [7], 2
[8] of the SOAP 1.2 specification and the Usage Scernarios as WDs? There
has been no objection to the Part 2/Sec 6 revised text [9], and it is
expected this will be added into the publication version.  Note editorial
comments [10].

Fallside: We have not seen the final HTML texts for the three pieces. We
would like to see the final versions of Parts 0, 1,2, and Usage Scenario
in their final HTML form before we send them to W3C.
Lafon: Final HTML will be available within an hour. 
Fallside:  There are no comments on Parts 0, 1, and 2. I propose to employ
the same review mechanism as for Orchard's texts, and to send WDs to W3C
for publication on Friday.

No objections received.

Fallside: If publication is succesful, the documents should be published
early next week.


8. Issue 170

ref'ing data that may be stripped from a message [11].  See Jacek's
proposed resolution [16], and subsequent discussion, including a couple of
modified proposals, [17b ] [18]

Henrik Nielsen and Jean Jacques had the most discussion about this issue.  
Henrik Nielsen noted this issue was discussed at the f2f, and he asked
what are the requirements for passing hrefs and actually dereferencing
them as part of message processing?  HFN noted some links are not
relevant, such a link to a photo of my dog.

Henrik: In case you want to resolve an href and you can't, this is the
fault you can generate. There was some follow-up discussion, Noah also had
a point and discussion died.

There are two issues that are slightly mixed up. Several proposals were

The first proposal is to always require resolution of an href and require
a fault. A second proposal says we don't say anything about requiring
resolution but if resolution is attempted and fails, it is a fault, and
the fault mechanism is used.

Noah:  Henrik seems to be responding to #168 which is related, but are we
talking about #170 now?

Henrik: Yes those are the two that I may have mixed up.

Noah agreed that we can put aside his comments about what a binding
specification should or can say about attachments. He was comfortable with
HFN's direction on Henrik's proposal about dangling hrefs that don't
relate to attachments. Noah surmised that SOAP might say a fault "may" be
generated vs a fault "must" be generated.  When using encoding There was
some dialog on serializing graphs (with missing edges, etc.). The sending
nodes may encode graphs (with hrefs) which are incomplete.  This is the
conversation that leads us toward #168.

Stuart suggested that IDRefs are more limiting and may be better in SOAP
messages than HREFs.  
David Orchard did say that Microsoft had in the past produced a Biztalk
canonicalization proposal that use IDRefs.

There was some debate about simplicity and consistency. The crux of the
issue is do SOAP processors have to look at all HREFs?

(Scribe's notes on the rest of this agenda item are incomplete.)
Ibbotson said there are two approaches:
1. The model itself links to resources
2. The encoding allows ability to express links to a resource.

Since there was no convergence of the discussion, Fallside ruled that the
issue should go back to email, and he noted that we need a way of bridging
two ideas: (1) within the SOAP model (2) the mapping of nodes and


9. Issue 171

attribute clashes on refs [12].  Do we accept Murali's proposed resolution
[13]? Murali drafted text for closing issue #171 based on the f2f
discussions surrounding this issue.  There were a couple of responses.  
Noah recommended that text be added to clarify the relationships between
xsi:type and graph nodes.  Murali did not have the opportunity to follow
up with Noah.  The other comment was from Jean-Jacques. We should talk
about attributes other than xsi:type, though Murali feels it might not be

Noah clarifies his point. He agrees with "if you want to know about
xsi:type to read the Schema spec".  He would like to see "Everything you
find in the Schema spec about xsi:type applies. Because we are describing
a graph model here, it is the case, that when you use an xsi:type as an
element, you are specifying the type of the node in the graph".

Noah: What is it do we want to say about schema validation? Schema
validation is not the issue on the table.  When you are doing schema
validation, the Schema spec tells you what xsi:type means and all that
applies.  Whether or not you are validating schema, when xsi:type names
one of the 12 built-in types, then essentially the node is typed

Two texts were included in Murali's proposal - minimal text and the
verbose text.  Though the minimal text is ok, it was generally agreed by
email that the verbose text is much better.  It specifically acknowledges
the problem expressed in issue #171.

Noah proposed (1) add before the second sentence the "type of node" (2) a
third sentence to say "Furthermore, regardless of whether schema
validation is employed, when xsi:type names is one of the built-in types,
the SOAP processor MUST recognize the node being the corresponding..."

Action:  Murali will expand the proposed (verbose) text taking into
account Noah's concerns by 12/13.



This agenda item was not discussed because it concerned an issue that has
already been closed.


11. Issue 40 (meta)

 support for resource constrained devices [19] During 11/14 telecon
discussion of this issue, we changed R309 (see 11/14 minutes) as a
prerequisite to resolving the issue.  Mark Baker has proposed resolution
text [20] in light of our change to R309. There were a couple more emails
on the subject - what is our final proposal? Mark Baker continues to work
on Issue 40. He needs to include Mike Champion's recent text.  There were
no other comments/discussions on this issue.  Discussion postponed for
next week's telecon.


12. Issue 117

clarify use of enc:offset and enc:position [21] (time permitting).  A
proposal is forthcoming, details shortly [22]. Glen Daniels' text is not
on the issues list and the feedback from his email was unknown. Glen
should forward status on his query to SoapBuilders.  Jacek said a related
issue #144 may be closed.

Action: Stuart Williams took the action to ping Glen to send his email.


13. Issue 173 Hierarchical Fault Codes

Henrik summarized the issue as how to handle multiple fault codes results,
for example like the XML dot notation.  After we decided to remove the dot
notation, the issue remained whether or not to have only one fault code.  
If fault codes are defined by arbitrary namespaces, we can have a
situation where a SOAP node does not know a particular extension has no
idea what is going on in the message.

Henrik's proposal is that the 1st fault code is defined in SOAP 1.2.  
Part 1 defines all that SOAP nodes will know plus additional q-names.  
This should not change the existing situation with respect to boxcarring.  
We want a relatively well-known mechanism for what went wrong and be able
to extend it with new fault codes.  The proposal is based on one from
Martin Gudgin and Rich Salz.  It does not change the SOAP fault mechanism
or the ability to carry multiple fault codes.

Fallside asked if in fact HFN's proposal differed from MartinG's in the
sense that MartinG's proposed fault value/fault subValue would exist in
hierarchical tree. HFN agreed that this was the difference.

Henrik advocates a "flat" SOAP fault mechanism with Value (MustUnderstand)
and Sub (May understand).  Sub is a specialization and there may be
multiple Subs at the same level. The other approach is hierarchical subs
in the SOAP fault.  Both approaches were discussed. Per Henrik, there is
only one value and multiple subs.

Doug Davis proposed to get rid of the sub and allow multiple values, with
the namespace of the value child be the indicator of whether you
understand it or not.  Fallside asked if there is a separator convention
between the value inside that value element.  Davis assumes there will be
different value elements.  There will be no distinction as what is
actually defined by SOAP or not defined by SOAP.  It would be identified
by the namespace. Fallside added that the content of the elements would
make the distinction rather than the surrounding elements.

Marc Hadley wondered about interoperability between SOAP versions if we
choose the the flat approach which is a change.

Fallside polled the group for those in favor of "flat" vs "hierarchical"
approaches. A large majority favored the hierarchical approach.

Action: Marc Hadley took the action to write a schema fragment to describe
fault code for hierarchical option by end of this week.