W3C XML Protocol Working Group teleconference, 9 January 2002

Minutes of XML Protocol Working Group telcon, 9 January 2002.

1. Roll call

Present 30/26 Excused Regrets Absent

2. Agenda review, AOB

3. Approval of 19 Dec 2001 XMLP telcon minutes


Minutes approved without objection.

4. Action item review

5. Status reports

--primer
--spec
MH: We received editorial changes from John Ibbotson.
NM: Some of JI's changes are stylistic, others are more profound and may
    require some debate.
JI: The concern I had with the processing model section was to take it as a 
    whole and restructure it.
DF: The editors should try to integrate John's comments: I suggest they make 
    the obvious and non-controversial changes and provide choices for the 
    suggested changes that are more debatable. 
--tbtf
--etf
--conformance
--usage
--XML Encryption's response to our review of their Last Call
DO: XMLE's response was that they had responded earlier to some of the 
    comments. More exchanges are on the way. Some of our comments on 
    Canonicalization were labelled as not related. It is not fair to 
    characterise XMLE's response as "we disagree". DO will comment on the 
    usage scenarios sent to us by XMLE.

6. Scheduling and issues


DF: We agreed to a schedule at the f2f, i.e. going to Last Call right after 
    the next f2f at the end of February. LC require that we have resolved all
    our issues. Currently we have ~56 issues pending, some are editorial, 
    some of relatively little import. Our task forces already own some of them,
    so the work of ETF and TBTF will be critical to closing the issues in 
    time. 
    It seems reasonable to have all our issues finished by the end of the f2f.
    However, some amount of time will be needed after the f2f to produce a 
    final spec. JI's work is an example of the type of work that will minimise
    the amount of post-f2f work.

7. Issue 170

DF: can resolution of the issue be framed in termns of deciding (i)
    must/should/may and (ii) idref vs href?
SW: The status quo at the moment is href, but changing to idref would change
    the outcome.
DF: So there are two decision steps (1) hrefs/idref and then (2) 
    may/must/should?
SW: Yes. For the Must/should/may decision, I suggest we gauge the 
    "live with" opinions.
HFN: I think choosing "may" is very important.
NM: Underlying the href/idref deicision is the issue of internal vs external
    links. On the one hand the web is "links are links", but on the other 
    hand in practical systems, local graphs are coherent models. So I think 
    we should first decide whether the distiction between those links exists
    or not? If we decide "no" then I think the answer should be "may".
DO: There is a grey area when you consider links within a package, like 
    SOAP+attachement. In this situation where is the notion of locality, 
    message of package? Also, IDs are usually associated with DTDs, and that
    may raise problems.
MH: The DTD argument is not valid because IDs and IDREFs are also in XML
    Schema.
JK: For practical reasons, if we go to IDREF then we don't lose any power but
    we get rid of many issues; and then we have distinct internal and external
    links.
HFN: According to the minutes of the f2f, it seems that we are more on the
     href side.
NM: Is a better way to look at this problem to consider all links encoded as
    internal? i.e., to view this as an encoding problem of graph links?
JK: More for separation ???
NM: What data tree model do we want to serialize, one like a programming 
    language or one more web-like?
HFN: If the link is external or if a jpeg in encoded and included in the xml 
     doc, it's the same thing.
MH: Here is another way to consider the problem: where do we draw the line, 
    what you expect the soap processor and the soap app to do?
More discussion followed.
DF: We will take this discussion back to email. Expect it to be raised again 
    at next week's telcon.

8. Issue 40

Ray has a proposal for new text.
NM: The text say "we are as small-device compatible as SOAP/1.1". The 
    requirement motivating this issue was vague because "resource constrained
    devices" are not well defined.
HFN: Is it worth spending much time on defining what small devices are? If so,
     will small devices even consider handling something like SOAP?
MB: +1
DF: (speaking not as Chair) Regarding the proposed text, I don't feel 
    confident with the SOAP/1.1 => SOAP/1.2 assertion, we should state that 
    we rely on other XML techs, and that we did things to minimize the cost of
    processing.
NM: +1
RW: Losing the first sentence (SOAP 1.1/1.2 assertion) is OK with me. The last
    paragraph is the most important, so the proposal is good.
DF: Are there any objections to closing issue 40 using Ray's proposed text but
    without the first sentence?
No objections.
DF: Issue 40 is closed with the modified proposal.

9. Issues 144 and 161

DF introduces JK's proposed resolution and notes 2 possible additions to the
   proposal (1) a note of the resulting difference between the arrays in
   SOAP 1.1. and 1.2, and (2) a note that the names of the array members are
   not significant.
JK: The names do not carry any semantic, and the name don't have to be equal
    for all the members of the array
HFN: There is no such requirement in SOAP/1.1 and in the current spec.
NM: The diff bewteen an array and a struct is that in an array members are
    accessed by number (position) and not by name. So in arrays names can't
    be used as accessors.
DF: Are there any objections to closing issues 144, 161 and 117 using JK's
    proposal and with the addition of notes saying that (1) arrays in SOAP
    1.1 and 1.2 are different, and (2) names of array members cannot be used 
    as accessors?
No objections.
DF: Issues 144, 161 and 117 are closed with the modified proposal.

10. Issue 168

NM: The proposal was "we are not constraining what is at the end of an href",
    and When there is no type information, it should be considered as untyped
    and we should create the a node with a name but no type.

It was decided to skip discussion of this issue becuase its resolution is so 
dependent upon the resolution of issue 170 which we decided to take back to an
email discussion.

11. Issue 47

DF: Are there any objections to closing issue 47 using the ETF's proposed text?
No objections.
DF: Issue 47 is closed with the proposal.

12. Issue 164

JK: The issue is how to map arrays to XML schemas for languages like WSDL. 
    Now that issue 144 is fixed, we should not provide mapping to schema and 
    back, and we should stay on the current status quo.
DF: Are there any objections to closing issue 164 by retaining the status quo?
No objections.
DF: Issue 64 is closed.

13. Issue 174

NM: SOAP has attributes and elements, but mostly attributes like 
    mustUnderstand. We should establish consistent terminology with regard XML
    datatypes, e.g. use only one boolean lexical form. Howver, we should say 
    that different legal lexical forms are allowed, e.g. mustUnderstand can be
    "true" or "1". The last sentence of the proposed text also says that when
    an intermediary passes a message, it should not change the lexical form, 
    e.g. from "1" to "true".
HFN: It might be difficult to ensure that is the case in practice.
DF: Any objections to closing issue 174 with Noah's text without the last 
    sentence, and to opening a new issue to deal with changes to lexical forms?
No objections.
DF: Issue 174 is closed with the modified proposal.