W3C XML Protocol Working Group teleconference, 24 October 2001

Minutes of XML Protocol WG telcon, 24 October 2001.

1. Roll

Present 31/24 Excused Regrets Absent

2. Agenda

No AOB. Will replace agenda item #8 with report on moving forward with SOAP
with Attachments etc.

3. Approval of Oct 17 telcon minutes

Approved, including amendments from Jean-Jacques sent in
http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2001Oct/0173.html

4. Action items

Issue 30 (PaulC)
PaulC: not done, he is busy; always gets the non obvious ones; will work on
it after this week's Prof. Dev. Conf.

XMLQuery (PaulC)
PaulC: pending, has drafted a message; will send it this week.

Property feature (TBTF)
Not done

Issue 12 (ChrisF)
ChrisF: pending, will send a copy of response note to DavidF

Usage scenarios (JohnI)
Done, they were sent to Hugo

xml:base
DavidO: done, did send proposal to dist-app

application/xml media-type (Editors)
Gudge: done

SMIL + SVG media type (Hugo)
DavidF: Hugo absent; will report back next week

Feedback IETF (MarkN)
MarkN: done, was sent today

Revive intermediay header discussion (Noah)
Done

5. Status Reports

a) f2f
ChrisF: Videconferencing facility is indeed available
DavidF: Who would participate in a videocon?
-- Many ratified, including US members
DavidF: Video may need to be primarily one-way from the f2f facility if
there are many sites, and we may need to decide on a procedure for external
sites to speak. Take this topic further in email.
ChrisF: Network is Sun-only. No wireless. No Internet.
DavidF: Can at least one PC have Web access?
ChrisF: Yes, need to investigate further.
PaulC: Telcon instead of video?
ChrisF: Room is wired for telcon.
DavidF: Ideally, we will use both. Do the telcon and videocon facilities
interact?
ChrisF: Will investigate.
PaulC: What is the preferred (in terms of cost/distance/etc) hotel?
ChrisF: None.

b) Primer
Nilo: No progress, no comments, apart from ChrisF and teleconf. Only able
to move paragraphs around so far. Need comments.
DavidF: WG decided the Primer needs a gentler ramp up in presentation of
concepts. Go ahead and do it.
Nilo: Thought about moving some sections around.
DavidF: Was on my own for Schema primer. Went ahead. Got more feedback as
time went by.
Nilo: Next draft in 3 weeks, in time for f2f.

c) Spec
Gudge: Editors plan to work on spec this week and next.

d) TBTF
Highland: Have now one binding instance. Generated discussion on dist-app.
Meeting this morning and Friday.

e) ETF
Jack: Discussed proposal for issue 30. Noah raised new issue. More issues
raised than solved so far, but feels this is a temporary situation.

f) Conformance
Yves: Nothing to report, said Hugo.
DavidF: Slow progress, said Oisin.

g) Usage scenarios
[JohnI absent]
DavidF: comments? [silence] Any one read it?
Gudge: Yes, comments later this week.
DavidF: Is it headed in the right direction?
Gudge: Yes.

6. Telcon dates

DavidF: Proposes no telcon for day before U.S. Thanksgiving, and the
telcons during the weeks of Christmas and New-Year.
DaveO: Why not the day before TG?
DavidF: Because large number of US participants may not be able to attend.
DavidF: Who would not be able to attend?
-- No responses
David: Propose to cancel only telcons on December 26 and January 2.
-- No disagreement voiced. DavidF directs W3C staff to update member page
accordingly.
Stuart: Notes that clocks will change this weekend, although this is is not
a proposal for anything.
DavidF: Am aware of this, will see if it has any imapct, e.g. to Yin Leng
in Australia.

7. Issue 134, xml:Base support

DaveO: Noah's original proposal: no xml:base, no relative URIs. Latest
proposal: allows relative URIs.
Henrik: New proposal is not just about xml:base attribute, but also
includes bindings, eg. HTTP.
DaveO: We need to clean up protocol binding.
DavidF: A friendly amendment was made to DaveO's proposal, URI anywhere.
Original proposal from J. Marsh: URI anywhere, but SOAP URI are absolute.
What is the difference?
DaveO: ????
Gudge: It is the same as DaveO's. Henrik's proposal is ok.
Henrik: xml:base refers to RFC2396, and by implication to HTTP base.
Gudge: We need to call this out.
MarcH: Protocol does not necessarily define base, but media type does.
PaulD: Is there a defined order of precedence when there are multiple base
definitions?
DavidF: Ordering is between child/ancestors.
DaveO: The most recent thing wins.
Gudge: Does already, see section 4.1.
DavidF: Proposal:
  i) xml:base on any element
  ii) relative URIs on any element or attribute, including relative URI's
for SOAP 1.2 namespaces
  iii) protocol binding can set base
Gudge: relative namespace URI not allowed by W3C.
DavidF: New proposal, just i), ii) and iii) from above, but without
realtive URI's for namespaces
Henrik: So xml:base is fully supported.
DavidF: Is there any objection to accepting this proposal?
-- No objections raised
DavidF: The proposal is accepted. Send text to editors.

8. Issue 165, dereferencability of URIs

DavidF: Postpone this agenda item due to Noah's absence. Instead, want to
briefly mention what is happening with regard the SOAP+Attachments
discussion from last week. In summary, we would like to be confident that
S+A is taken up at a later date. The venue for such work could be a new WG,
eg. packaging. Currently investigating a number of options, including with
the XML Cordination Group. We may not take on S+A right now, but we need to
make sure it is bolted and will happen in the future. Is there any
discussion?
PaulC: If the work is to happen inside the XML activity, it needs to happen
in next 30 days.
DavidF: Yes, I have already contacted members of the CG about that.

9. Issue 30, references to data outside the serialisation

DavidF: ETF has discussed this, and proposed a resolution.
Jack: ETF thinks issue can be solved by removing id and href attributes,
and by some cleaning up in the spec. Section @@@ would instead clarify the
meaning of these attributes. In addition, Noah pointed out there is another
issue.
Henrik: To summarise, the ETF is proposing the URI can be of any type, and
can point to anything!
Jack: Yes.
PaulC: Are there conformance implications for XML binding?
Jack: No, the proposal references XML linking.
PaulC: Ok.
Henrik: Yes, the proposed text references XML linking.
Jack: The text is taken from original text. It is meant to be
non-normative.
PaulC: So no conformance implication?
MarcH: There is an issue with id and no DTD.
Jack: This is raised under a separate issue #163. They are orthogonal
issues.
MarcH: Issue 30 will break the resolution of issue 163.
Gudge: More work needed, then.
Stuart: Is the action on PaulC about issue 30 redundant then?
PaulC: We have not talked against proposed resolution so far...
DavidF: ????
Gudge: Because of infoset, we could say id is of type "xsd:type", ok?
PaulC: Yes, that would work.
MarcH: Is XML Schema id different from DTD id?
Gudge: Yes, they are not type compatible, but share same characteristics.
MarcH: What about DOM compliance?
Gudge: DOM does not yet support Schema.
MarcH: Will they?
Gudge: Yes, I believe so. I need to check a couple of implementations.
DavidF: ????
MarcH: We should not mandate XML schema processing.
Gudge: Not necessarily true. We need only understand "xsd:type", so there
is no conflict.
Jack: There are two issues: 30  and 163. Issue 163 will apply as well.
MarcH: Disagree. There is only one place in spec where we use id and href.
Jack: ????
Gudge: ????
DavidF: We simply have to indicate the scope of URI. This is independent of
how we resolve 163.
MarcH: Ok, just pointing 2 issues are dependent.
Jack: We are simply consolidating text, and expanding where id is not
relevant.
DavidF: Is there any objection to the proposed resolution of issue 30?
-- No objections raised
DavidF: The resolution is adopted. Editors to act on proposed text. Jack to
write email to xmlp-comments.

PaulC: I need to double-check what my old action item was.
DavidF: .... And come back to us if there is still an issue.
PaulC: Ok.

10. Issue 146

Stuart: This is similar to issue 140. It does not quite capture the
secondary issue in 140.
DavidF: Does anyone remember?
Stuart: Noah may.
Stuart: Perhaps we should defer this until it is cast clearly?
DavidF: Yes, we will postpone, it does not seem well formulated. Staurt
should figure this out before end of week.

11. Issue 141

Stuart: Body blocks are equivalent to header blocks with mustUndertstand
set to true, and addressed to default actor. Headers must be namespace
qualified. Body _may_ be namespace qualified.
Gudge: Historical artifact when translated spec to infoset. Body should be
namespace qualified.
Henrik: Dates from when namespaces were optional, body were kept separate,
since receiver was able to use other mechanism. However, we do now require
namespaces on the envelope, so I have no strong opinion. Should we check
soap builders?
Gudge: Since namespaces are used to check headers, they could be used to
check the body as well.
DavidF: There appaers to be acceptance for changing "may" to "must". Is
there anything else to consider?
-- No response
DavidF: Should we wait for soapBuilders's feedback or edit the spec
immediately?
Jack: The change would not change implementations much.
DavidF: Henrik?
Henrik: Yes, if email to soap builder as well.
DavidF: Is there any objection to making the change plus soliciting
feedback from soapBuilders?
-- No response
DavidF: Accepted. Editors to make the change. Gudge to send email to
xmlp-comments and soap builders.

12. Omnibus proposal to close issues 104, 101, 64.

DavidF: Issue 104: spec to use infoset. The originator, Noah, is happy.
DavidF: Issue 101: special status of body, processing with respect to
header. Dinard's new processing model clears this issue up.
DavidF: Issue 64: about specification of envelope; misunderstanding, since
schema does exist.
DavidF: Can we close all of these in one vote?
MarcH: I have an issue with 64, I am ok with closing the others.
Yves: Hugo said we cannot close 101, I don't know why.
DavidF: In that case, we'll decide on the issues individually. Is there any
objection to closing issue #104?
-- No objections
DavidF: Issue #104 is closed, per the proposal. Regarding issue #101, did,
did Hugo have an issue?
Yves: I am waiting for email from him.

MarcH: With reagrd issue 64, the initial email concerned binary data. So,
closing it is premature, and we need to wait for a decision on
SOAP+Attachments.
DavidF: Will it be OK to close issue 64 once a stake is in ground for
handling S+A?
PaulC: Any other issues related to this (S+A)?
DavidF: No, just 61. Status quo is to @@@
Henrik: Need a mechanism for 701a (the requirment that motivates issue 64).
Gudge: Cites 701a ("The XMLP specification must define the concept of an
envelope or outermost syntactical construct or structure within which all
other syntactical elements of the message must be enclosed. The envelope
must be described with XML Schema."). So, I think transporting application
data is a seperate issue.
MarcH: Agree with Gudge. It is separate, so I am taking back my own
objection.
DavidF: Is there any objection to closing 64 per the resolution proposed in
the agenda?
-- No objection raised
DavidF: Issue 64 is closed. Need someone to send resolution email to
xmlp-comments ....
Gudge: Will do.

David: Regarding issue 101, any answer yet from Hugo?
Yves: No.
David: Please send email asking Hugo for clarification.
Yves: Done.

DavidF: We are at the end of the agenda, and we have 10 minutes left. Shall
we adjourn or take on another issue?
Henrik: Should we discuss f2f logistics?
DavidF: Please do that by email.
PaulD: 101 is for a node receiving a message, what about sending node?
DavidF: Are you suggesting a need to clarify sending and receiving roles?
PaulD: Yes, perhaps clarify in separate sections, or a few extra words.
David: I don;t think this is an issue per se that we can discuss now.
Henrik: We should not use the processing model for generating soap
messages.
DavidF: I am skimmming through the issue list.
Henrik: How about issue 65?
David: Issue 65, "define the processing model" based on requirement 701b. I
propose we close this issue by pointing to our clarification of the
processing model. Does anyone object to this resolution?
-- No objections
DavidF: Issue 65 is closed. Henrik to send email to xmlp-comments.
DavidF: Any other suggestions for closure?
???: How about issue 37?
DavidF: Originator is Stuart.
-- Meeting adjourned