Minutes of XML Protocol Working Group telcon, 9 January 2002.
1. Roll call
- Active Data Exchange Richard Martin
- AT&T Mark Jones
- BEA Systems David Orchard
- Canon Herve Ruellan
- Cisco Raj Nair
- DaimlerChrysler R. & Tech Mario Jeckle
- Ericsson Research Canada Nilo Mitra
- Fujitsu Limited Kazunori Iwasa
- Hewlett Packard Stuart Williams
- IBM John Ibbotson
- IBM David Fallside
- IBM Noah Mendelsohn
- Intel Highland Mary Mountain
- Macromedia Glen Daniels
- Matsushita Electric Ryuji Inoue
- Microsoft Corporation Henrik Nielsen
- Microsoft Corporation Paul Cotton
- Netscape Ray Whitmer
- Oracle Anish Karmarkar
- Oracle Jeff MischKinsky
- Philips Research Amr Yassin
- Planetfred Mark Baker
- Rogue Wave Murali Janakiraman
- SAP AG Gerd Hoelzing
- Software AG Michael Champion
- Sun Microsystems Marc Hadley
- Systinet (IDOOX) Jacek Kopecky
- Tibco Frank DeRose
- Unisys Lynne Thompson
- W3C Yves Lafon (Scribe)
- Active Data Exchange Shane Sesta
- AT&T Michah Lerner
- Canon Jean-Jacques Moreau
- Cisco Krishna Sankar
- DaimlerChrysler R. & Tech Andreas Riegg
- Fujitsu Limited Masahiko Narita
- Intel Brad Lund
- Macromedia Simeon Simeonov
- Netscape Vidur Apparao
- Philips Research Yasser alSafadi
- Rogue Wave Patrick Thompson
- SAP AG Volker Wiechers
- Software AG Dietmar Gaertner
- Sun Microsystems Chris Ferris
- Systinet (IDOOX) Miroslav Simek
- Tibco Don Mullen
- Unisys Nick Smilonich
- W3C Hugo Haas
- Compaq Yin-Leng Husband
- Data Research Associates Mark Needleman
- Interwoven Mark Hale
- IONA Technologies Oisin Hurley
- Mitre Marwan Sabbouh
- Mitre Paul Denning
- Compaq Kevin Perkins
- DevelopMentor Martin Gudgin
- DevelopMentor Don Box
- Interwoven Ron Daniel
- IONA Technologies Eric Newcomer
- Martsoft Jin Yu
- WebMethods Dave Cleary
- WebMethods Asir Vedamuthu
2. Agenda review, AOB
3. Approval of 19 Dec 2001 XMLP telcon minutes
Minutes approved without objection.
4. Action item review
5. Status reports
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.
--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
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
DF: So there are two decision steps (1) hrefs/idref and then (2)
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
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
HFN: According to the minutes of the f2f, it seems that we are more on the
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?
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
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?
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
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
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
11. Issue 47
DF: Are there any objections to closing issue 47 using the ETF's proposed text?
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?
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?
DF: Issue 174 is closed with the modified proposal.