W3C XML Protocol Working Group teleconference, 2 April 2003

1. Roll call

Present 18/14 Excused Regrets Absent

2. Agenda review, AOB

3. Approval of minutes of previous telcon

March 26 minutes not yet posted. Item postponed.

4. Action items.

- n11n published - done
- Fix TOC - done
- empty string in xs:anyURI - done
- Role="" clarification - done
- Create CR issue - done
- Rough draft for Action feature - done
- Clarify on R21 and R31 - done

5. Status reports

- Part 0, 1, 2
 Nothing done

- Test collection
 No report

- Registration of media type
Yves: made a draft, sent to Mark Baker, who will make some modifications,
then it will go for publication.
Changes are to basically remove everything (??) and add links to ??
specification.

- IPR
 No changes

6. CR progress and issues.

* 420 - empty role URI and test collection doc.
- Empty role issue
GD: some implementation are using "" as valid role attribute, some treat
it as equivalent of ultimateReceiver. Problem: is "" allowed as an URI.
DF: in LC draft, "" was equivalent to the ultimate receiver. However
this conflicts with the use of base URI (issue 233). Resolution of 233
was to remove the equivalence of "" with ultimateReceiver.
Gudge: according to the specification, URI can be empty.
-> No one disagrees with Gudge's findings.

DF: there are some errors in the test collection document, these were
probably things which were not updated from LC document.
DF (to the WG): is it OK to fix test collection document?
-> No one disagree.

DF: it is suggested that we provide some guidance of what is the value when
role is "". Such guidance would be put in the primer.
Jacek: is this a change from SOAP 1.1?
Noah: 1.1 is silent about this.
-> WG decides it is OK to put such guidance into the primer.
DF: 420 is now closed.

* CR implementation report
DF: implementors came with a list of issues and action items after their
call last friday. Consider each list item in turn.

-- trace for feature 47 uses LC NS and the envelope tag is missing a NS.
Missing NS on envelope is an issue.
Should we delay going to PR the basis of this type of omission?
Recommendation is to wait one more week before going to PR as there are
still traces and fixes in the pipeline.
JI: what W3C will think about this NS problem?
YL: think it will not be a problem

-- missingID and DuplicateID: only one implementation.
Some talk about necessity to having tests for these features because they
are not mandatory features.

-- encodingStyle attribute on the body element is incorrect in CR. Will be
only be partly corrected.
Yves: goal to show that the change did not create problem.

-- ???

-- Fixes for feature 48.
Glen: feature 48 will be in Axis endpoint.
ACTION to Glen to have Axis endpoint up and running by Friday.

DF: in summary, a number of fixes in the pipeline to make the table better,
but transition from LC to CR implementations is clearly not complete.
However, we are hoping that the implementers will come to next week's WG
telcon saying that they're done.

* 419 - SOAP Action as property
Glen: JJM and Glen wrote a feature for setting the value of the SOAP
Action parameter. Need a slight change in the HTTP binding to say it
supports this feature. Parameter should be a URI and not a string
(comment from MB). No other comment.
Gudge: feeling good.
DF: "implementation will not need to do anything different", is this really
true?
Glen: Depends on the implementation. Only if implementation has a concrete
representation of features and properties.
Jacek: change in the spec will be welcome.
Glen: the feature will cause no change in the Axis implementation
Jacek: the feature will cause no change in the Systinet implementation
Glen: change later on to support features. Probably with WSDL
implementation.
Jacek: same for Systinet.
DF: straw poll for adopting the proposal.
 - yes: 8
 - no : 1 (but not a strong objection)
DF: is the proposed text ready to go in the spec?
Gudge: it needs some introductory text.
Glen: the proposal contains introductory text.
DF: here is the formal question, is there any objection to resolve 419 by
adopting changes to
the spec from Glen email as ammended by Mark Baker (change xsd:string to
xsd:URI).
-> No objection.
DF: issue 419 is closed with this resolution

* 421 - comments
Noah: SOAP envelope description seems to preclude comments completely.
However, there are rules for relaying them.
Gudge: Agree.
Noah: I think the WG's intention was to allow them in many places. If so,
it should be an editorial change. Proposal solution to allow comments.
Gudge: ???
Noah: imply no comment in body. A better solution is to say _where_ we
allow comments.
Gudge: do not allow comments before or after the envelope. We could add a
statement at start of section 5 to say that comments are allowed as
children of envelope.
Noah: is it an obligation to transmit comments? I think not.
Marc?: do not remove in body or not target header as is may break
signature.
Noah: add note in binding framework. Need not transmit comments, but care
should be taken when signature is used.
John: what is the situation with regard canonicalization?
Gudge: two algorithms: one that keep comment, other that does not keep
comments.
Noah: what if the binding does not want to care about the comments, in the
1 hop scenario. Does the binding have to transmit the comments?
DF: how does implementation handle comments.
Gudge: think they are not preserved.
Glen: present them in the model, but does not mean an intermediary build
upon Axis will preserve them.
Glen: comments are part of the infoset, so binding should transmit them.
Noah: same for PIs.
DF: we need to think further about this. Treat this issue in two parts.
-> Conclusion:
 1 - comments should be allowed a children of anything in the
envelope NS (seems to be an agreement over this)
 2 - what are the obligations of binding about this? Need more
thinking about this.
DF: we'll take this topic to email. Some people to come with pro and cons.

* DF: has there been any pushback on any issue?
-> None

7. Attachments

DF: are there any questions about the proposal?
Noah: one issue: xquery data model very close to this proposal. Where does
it fit architecturally? I would like some discussion about this.

DF (to W3C staff): has there been any new discussion in the team about this
proposal?
Yves: no new discussion. The team's earlier response stands.

DF: meeting adjourned.