Minutes of the XMLP WG telcon on 23 January, 2002.
1. Roll call
- BEA Systems David Orchard
- Canon Herve Ruellan
- Cisco Raj Nair
- DevelopMentor Martin Gudgin
- Ericsson Research Canada Nilo Mitra
- Fujitsu Limited Kazunori Iwasa
- Hewlett Packard Stuart Williams
- IBM John Ibbotson
- IBM David Fallside
- IBM Noah Mendelsohn (scribe)
- Intel Highland Mary Mountain
- Martsoft Jin Yu
- Matsushita Electric Ryuji Inoue
- Microsoft Corporation Henrik Nielsen
- Microsoft Corporation Paul Cotton
- Mitre Paul Denning
- Oracle Anish Karmarkar
- Oracle Jeff MischKinsky
- Philips Research Amr Yassin
- Rogue Wave Patrick Thompson
- SAP AG Volker Wiechers
- Software AG Michael Champion
- Sun Microsystems Marc Hadley
- Systinet (IDOOX) Jacek Kopecky
- Unisys Lynne Thompson
- Unisys Nick Smilonich
- W3C Hugo Haas
- Rogue Wave Murali Janakiraman
- Canon Jean-Jacques Moreau
- Cisco Krishna Sankar
- Fujitsu Limited Masahiko Narita
- Intel Brad Lund
- Mitre Marwan Sabbouh
- Philips Research Yasser alSafadi
- SAP AG Gerd Hoelzing
- Software AG Dietmar Gaertner
- Sun Microsystems Chris Ferris
- Systinet (IDOOX) Miroslav Simek
- W3C Yves Lafon
- Zolera Rich Salz
- Tibco Don Mullen
- Tibco Frank DeRose
- Active Data Exchange Richard Martin
- AT&T Mark Jones
- Compaq Yin-Leng Husband
- DaimlerChrysler R. & Tech Mario Jeckle
- IONA Technologies Oisin Hurley
- Netscape Vidur Apparao
- Netscape Ray Whitmer
- Planetfred Mark Baker
- WebMethods Dave Cleary
- WebMethods Asir Vedamuthu
- Active Data Exchange Shane Sesta
- AT&T Michah Lerner
- Compaq Kevin Perkins
- DaimlerChrysler R. & Tech Andreas Riegg
- Interwoven Mark Hale
- Interwoven Ron Daniel
- IONA Technologies Eric Newcomer
- Macromedia Glen Daniels
- Macromedia Simeon Simeonov
2. Agenda review, and AOB
AOB itme: FTF Hotel deadline extended to 1/31
3. Approval of January 16 telcon minutes
Minutes approved as posted without any changes.
4. Review action items
Question from Paul Cotton: where do we stand on charter extension?
DF: he is preparing a draft. Paul C: CG would like to know about it.
AI maintainers to add an action item back to AI list.
5. Status reports
-- Primer Nilo: has incorporated some comments from XMLP comments
-- Spec Hierarchical fault codes resolution added. Mail sent on related
question for RPC fault codes...temporary solution in the spec. Part 2:
href -> idref change made, array encoding changed, comments welcome. Sent
out some requests for comments on rewrite of part 2. Find links to editors
drafts on public page.
-- TBTF There will be a second binding, tentatively in the primer, for
SMTP. Paul Cotton expressed concerns that this should not delay
publication schedule, including to last call. TBTF group will approach
David to reconsider whether to publish SMTP binding in primer, as a W3C
Jacek: apart from what's on today's agenda, the ETF made a decision to move
away from XML schema in the examples. Decided to repost for further
discussion examples regarding missing data.
-- Conformance work: Hugo: goal is to incorporate stuff from last ftf, and
now that IPR issues cleared, from the soapbuilders tests. Short of time,
not sure whether Oisin has time. David F: any volunteers? No one
volunteered. Paul Cotton: what about people who work for members but not
in the WG? David F: OK, send me one. Anish volunteers for conformance
work. Jeff Mischinsky volunteers as well.
-- Usage Scenarios
John Ibbotson: latest were released as part of WD for comments. None
received. John is not aware of any outstanding to do's, except for some
editorial comments from colleagues at IBM. He is waiting for more comments
6. xmlp-comment proposal
MartinG has looked through the comments posted against our recent WDs and
he has proposals for how to deal with each one of them .
The recommendations are referred to as:
Non-issues (a) (b)* (c) (d)
General (a) (b)
Part 0 (a) (b)
Part 2 (a) (b)
JacekK has raised a comment against 'non-issue (b)', see , in which he
claims the text in the WD is present in error and he proposes a different
resolution. Do we accept MartinsG's recommendations incorporating JacekK's
Yes...accepted without any dissent. Implementation of this decision goes on
editors' to-do list.
7. Issue 170, ref'ing data that may be stripped from a message
What is the spec language that describes when to generate a fault given the
existence of a non-dereferencable IDREF? The discussion revolves around
MUST, SHOULD and MAY. Jacek has proposed text that includes "MUST" .
There has been discussion around this proposal that appears to partly hinge
on the interpretation of the phrase ".... a reference to a missing ID is
found, the application MUST generate a fault ....", and whether this
implies that a processor is obligated to look for such references.
Long debate about MUST/SHOULD etc. Chair takes informal poll on:
"When SOAP Encoding data is being dereferenced and a reference
to a missing ID is found, the application (strikethrough: MUST )SHOULD
generate a fault
with faultcode env:Sender and subcode enc:MissingID."
9 in favor and 1 (Henrik) expresses concern that SHOULD is strong in its
implications. Using it in this way may undermine interoperability in that
some will presume that well-written implementations WILL generate the
fault, and won't do the right thing when the fault isn't there. However,
Henrik can live with "SHOULD".
Formal proposal: to close the issue with the revised text as above. No
objections, issue closed.
Mike Champion will be exploring the question further, preparing an email,
which MAY result in related questions being (re)opened.
8. Issue 168, type of referenced data
The ETF proposes to keep the status quo for this issue, i.e. to require
that every value is typed . Does the WG accept this receommendation?
Jacek: the issue went away, given that we now use ID/IDREF. Noah: but
there's a question about whether the status quo does type every node? What
if there's no xsi:type and no validation? After some discussion, there
seems to be a agreement that we need to say something about this case.
David F: The ETF need to propose text to cover this, as part of the
resolution of 168 (which remains open), though with an understanding that
all are agreed that the original question regarding external data is
9. Issue 137, intermediaries relaying SOAP messages without modifying them
 (1.10 + 20)
The issue concerns applications/intermediaries that may need to modify
blocks that are not targetted at them. The issue's originator provides a
number of alternatives :
iii) 'soften to SHOULD'
iv) 'new mechanism'
Can we pick one of these alternatives?
Discussion of this issue assumes it is indeed a dupe of #175 . Issue 137
refers to what is now the last paragraph of section 2.6  (not the Note
Henrik proposes: default is that intermediaries can do just about anything
to a message, headers can be used to tighten the rules.
Noah: I like the idea, but I think the default has to be the opposite. If
a sender does not give permission for the message to be mangled, it should
go through intact. Otherwise, how does SOAP help you at all? Any message
you send could be changed in arbitrary ways (e.g. change the amount of an
update on a bank account.)
Discussion on which should be the default.
David F: We are out of time, we will take the discussion to email and
revisit it next week.