W3C XML Protocol Working Group teleconference, 03 April 2002

1. Roll Call

Present 29/25 Excused Regrets Absent

2. Agenda Review and AOB:

DavidF:  Adding a new agenda item at the end of status reports to allow some time to
ensure we identify loose ends, issues missed.
DavidF:  Asked W3C for temporal extension to the working group charter. W3C will have
a response to us by the end of next week.

	

3. Approval of Minutes:

Several corrections to the 27 March 2002 minutes were received.  
DavidF:  Will take AI to revamp minutes with Jean-Jacques and Highland's comments.
Approval of minutes postponed.

        

4. Notes from review of Action Items:

--JohnI - deal with editorial ed notes in usage scenarios document. Hopes to clear/resolve
by next week.
--MarkJ/JohnI - work with Conformance Eds to generate tests for remaining assertions.
JohnI:  Have not been able to get hold of a resource to help out.
MarkJ:  Finished majority of tests.  
--Jean-Jacques - send closing text with regard to issue 189.
Jean-Jacques:  One loose end.  As a result of discussion on 189, was there a suggestion
to raise a new issue?
Henrik:  Needs clarification WRT what can be part of the envelope infoset. The Editors
took it (on to-do list).  Will have to go through the working group, but consider this
issue closed.
Noah:  May go beyond editorial changes, depending on how it's resolved.
This AI on 189 for Jean-Jacques closed.
--JacekK/RayF - propose clarifying text in part 2 and summarize proposal for dealing
with [8].
JacekK:  Will have a proposal or two for next week's WG telcon.
  
        

5. Status Reports:

--Primer:  Nothing to report.
--Spec:
Henrik:  When should next snapshot be generated?  Current one is from 23 March. Can
create one on short notice if people think it's useful.
DavidF:  Confused about snapshot versioning scheme - snapshot vs. editors' copy. Is it
true that the content at the end of the sanpshot URL does nor change, and the content
at the end of the ed copy URL does change?
Henrik:  Yes: Snapshot is frozen image of editors' copy - editors' copy is the working copy.  
Noah:  Review of 23 Mar snapshot ends Friday 5 Apr.  There will be a 'quiet time' while
editors chew on comments - another snapshot could be posted for review once round of review
on 5 Apr comments done.
DavidF: Yes, this is the plan.
--TBTF:  
DavidF:  Largely on track.  WRT resolution for issue 196 two questions:  do the TBTF people
have action items - were there more since the agenda item was sent out?  If not, does anyone
have commentary on the TBTF direction for resolution to 196?  
Group:  Answers were no and no.
Noah:  Some interest in HTTP status codes from the TAG.
--Conformance Work
Oisin:  Not much progress since last call.  Updating assertions text with 23 Mar edition of
spec, which is proving a larger task than initially thought.  MarkJ putting together tests
that will be incorporated.  Will not be migrated by the end of week - perhaps by the next WG
telcon.
--Usage Scenarios
JohnI: There is one more ed note to sort out. It should be ready by nearly next week. Have
noticed the the doc version on group page is dated 17 Dec.  A revised copy was submitted
which hasn't been published yet.
Yves:  Will go through email and publish what needs to be published on friday, including
Editors' draft of usage scenario doc.
--Requirements Document.  Nothing to report.  BobL is waiting on DavidF item.
--Email Binding.  Nothing to report.
--Web Services CG regarding Semantic Web/RDF, issue 29
DavidF:  XMLP now part of the web services activity, which includes a web services coordination
group.  DavidF chairs this cg - membership comprised of leads from web services architecture group,
web services description group, representative from semantic web, and the activity lead for web
services from W3C. One topic discussed in the WSCG call this week was RDF's response to our query
for feedback on issue 29. In reviewing our charter to ensure we meet our obligation regarding
serializing data representing non-syntactic data models, the critical sentence seems to be that
the WG  "...should propose a mechanism for serializing data representing non-syntactic data models
in a manner that maximizes the interoperability of independently developed Web applications."
Serialization must maximize the interoperability of independently developed applications. Can we
transport existing serializations of those non-syntactic data models, i.e. XML serializations of RDF
graphs, MOF UML models, our data model?  RDF's Eric Miller's answer is that they have agreed that
it is possible to transport serializations of RDF graph in SOAP messages.
Mario:  Received a response from XMI - they say it is possible to transport XMI in SOAP. Definition
of an XMI encoding for SOAP is required, but it is possible.
DavidF: Issue 29 can be closed with the agreement from RDF and XMI that it is possible to transport
their models in SOAP messages using either RDF XML serialization or the XMI serialization. There is
a further degree of interoperability that is possible, which is to align data models or serialisations.
For example, XMI would like to use the SOAP encoding to transport UML/MOF models rather than invent
a new serialisation. Also, RDF would like to reconcile their DLG with our data model for a similar
reason. To this end, RDF will come back to us in two weeks with a ballpark estimate of differences
between their data model and ours. They have agreed to give us a single point for this come-back, and
to name that person by the end of this week. RDF does not think this activity should hold us back from
going to Last Call.
??: Why would W3C want to reconcile the SOAP Encoding with RDF?
DavidF: W3C wants to maximise interoperability, and it would do this by ensuring there are not small
and gratuitous differences between data models and encodings.
--"application/soap+xml" media type
DavidF:  Suggest we reference the media type proposal MarkB drafted and sent to IETF.  Are people
happy with it?
ChrisF:  Sent MarkB some issues that need to be addressed, mostly editorial - some slightly technical.
These issues should be logged and addressed.
Henrik:  The proposal is not linked in from the public WG page
DavidF:  That should be done.

5a.  New Agenda Item - loose ends (missed issues, etc): 
--ChrisF raised issue (above) regarding media type document
-- Noah identified a new issue regarding 193 and 12 (or 12 and 196?) tunneling chameleon?  Not sure.
MarcH has AI to verify that the issue is logged.
--Jean-Jacques/Herve raised issue regarding definition of intermediaries. Action to Yves to make sure
this is logged as an issue.
--JJM to investigate, and log if appropriate, a potential issue that was raised by Noah related to 189.  
 
        

6. Issue 197, Negotiation of Features in HTTP Binding

DavidF:  There are a couple of views WRT enablement for attachments in the HTTP binding:  (1) that it needs
to be more explicit WRT allowance of different mime types and (2) that the degree of explicitness can be less.
??:  Our binding should be flexible in the content type allowed such that it's extensible to carry stuff like
SWA or DIME packages.
Discussion regarding what has been agreed to and what is still under discussion with regard the TBTF's content
negotiation featur.
JacekK:  Questions regarding direction re: content negotiation - is it too HTTP specific? Prefers simple
approach outlined in Noah's proposal (adding words about attachments and MIME types, but not content negotiation).
Noah: Most recently we have looked at the absolute minimum required to get the spec to last call.  If we don't
say that the HTTP binding does content negotiation now, it would be an incompatible change to add it later.
DavidF:  There doesn't seem to be strong opinion on this issue outside of the TBTF membership, so it will be
the subject of the TBTF call tomorrow.

        

7. Issue 192, When is a Fault a Fault?

ChrisF:  The original proposal may no longer be viable given changes in Part 1.  
DavidF:  Is MarkB bringing up a different issue than 192?
Henrik:  Yes, regarding what to do when a SOAP Fault and an HTTP Fault are used together.  
DavidF:  Propose we revisit the 'meaning of body' discussion.  That will let us go on to take up Chris's proposal
(item [18] on the agenda).
Henrik:  Will write up a proposal for 'meaning of body' and faults with Jean-Jacques and Noah.
DavidF:  We'll wait to see the write up and put on the table with Chris's proposal to make a decision next week.

        

8. Issues gleaned from xmlp-comments and xml-dist-app.

--Part 2(b)
Gudge:  Commentator happy with resolution
ChrisF: Is this the same as issue 195?
JacekK:  No.  But it's addressed by the rewrite of sections 2 and 3 so we should close it.
No objection from the WG to closing the comment/issue in this manner.
Gudge:  Will send resolution to commentator.

        

9. Remaining Issues

--Issue 195 
JacekK:  He and Ray should have one or two proposals for this issue in time for next week's telcon.
--Issue 194 
Henrik:  March 19 proposal talks about encoding changing throughout the message. One way to do that is to say
 encoding style attribute applies to the value of the content and not itself - some examples in the proposal.
Have on the body element, not header or envelope, although each header block can have encoding style attribute.
ChrisF:  Confuses things to take this approach.
JacekK:  One proposal for dealing with different encoding style embedded in SOAP encoding - state that nodes
with different encoding style are terminal nodes.
JacekK:  Two options:  forbid changes of encoding style, or we can allow changes and then as proposed treat
changed data as opaque or terminal node - so we would not be in the middle of the graph but in a leaf of the
graph.  In that node, other changes could happen, but the node and its sub-tree, from the point of view of SOAP
encoding, would be just a simple node.
Henrik:  Sounds compatible with what he had in mind.
Gudge:  need text regarding summary of 2 issues - inaudible on call.
 
END OF CALL