Minutes of XML Protocol telcon, 16 January 2002.
1. Roll call
- AT&T Mark Jones
- Canon Jean-Jacques Moreau
- Cisco Krishna Sankar
- Compaq Yin-Leng Husband
- 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
- Intel Highland Mary Mountain
- IONA Technologies Oisin Hurley
- Macromedia Glen Daniels
- Matsushita Electric Ryuji Inoue
- Microsoft Corporation Henrik Nielsen
- Microsoft Corporation Paul Cotton
- Netscape Vidur Apparao
- Oracle Anish Karmarkar
- Oracle Jeff MischKinsky
- Philips Research Amr Yassin
- SAP AG Volker Wiechers
- SAP AG Gerd Hoelzing
- Sun Microsystems Marc Hadley
- Sun Microsystems Chris Ferris
- Systinet Jacek Kopecky
- Tibco Frank DeRose
- Tibco Don Mullen (Scribe)
- W3C Yves Lafon
- AT&T Michah Lerner
- Canon Herve Ruellan
- Cisco Raj Nair
- Compaq Kevin Perkins
- DevelopMentor Don Box
- Fujitsu Limited Masahiko Narita
- Intel Brad Lund
- IONA Technologies Eric Newcomer
- Macromedia Simeon Simeonov
- Netscape Ray Whitmer
- Philips Research Yasser alSafadi
- Systinet Miroslav Simek
- W3C Hugo Haas
- Active Data Exchange Richard Martin
- BEA Systems David Orchard
- DaimlerChrysler R. & Tech Mario Jeckle
- Interwoven Mark Hale
- Mitre Marwan Sabbouh
- Mitre Paul Denning
- Planetfred Mark Baker
- Rogue Wave Murali Janakiraman
- Active Data Exchange Shane Sesta
- DaimlerChrysler R. & Tech Andreas Riegg
- Interwoven Ron Daniel
- Martsoft Jin Yu
- Rogue Wave Patrick Thompson
- Software AG Michael Champion
- Software AG Dietmar Gaertner
- Unisys Lynne Thompson
- Unisys Nick Smilonich
- WebMethods Dave Cleary
- WebMethods Asir Vedamuthu
2. Agenda review, and AOB
Reviewed as posted.
AOB issue: telcon dial-in.
DavidF: W3C was not originally able to host the WG's telcons and so IBM has
been hosting. This will change, probably starting next week, when we start
using a W3C telcon bridge. Email about this will go out sometime Thursday.
3. Approval of January 9 telcon minutes
4. Review action items
5. Status reports
o nothing to report
o report from editors
o they have included text for the new data model in part 2
o some of JohnI's comments have been integrated into parts 1 and 2, and
the editors are meeting to discuss how to incorporate the rest
o they will produce one or two versions of the spec for the WG to review
-- aiming at end of week / beginning of next week
David: In order to go to Last Call we will need to resolve the spec's ed
notes. He suggests sending email pointing to the ed notes in the ed copy
and asking for final commentaries.
o they are identifying remaining pieces of work and who is responsible for
o some TBTF issues are in Agenda #6
o nothing to report
o David is no longer going to chair and scribe ETF meetings, they will
continue to work on their own
-- Conformance work
o Nothing to report
-- Usage Scenario
o Nothing to report
-- xmlp-comments: our recent WD publication has generated a number of
comments . We need a volunteer to peruse the comments and (a) identify
any substantive new issues for consideration by the WG, (b) propose
responses where possible and plans for responding otherwise.
o Martin Gudgin has volunteered to review xmlp-comments by end of this
6. The Chair proposes to close these 4 issues in a single decision.
-- Issue 12 / Issue 69 / Issue 131 / Issue 129 Decisions (see agenda):
o ChrisF, DavidF, NoahM, and DavidF gave overviews, respectively.
o DavidF asked for any objections to closing all four issues.
No objections were raised.
o DavidF ruled that issues 12, 69, 131, 129 are closed.
7. Issue 170, ref'ing data that may be stripped from a message 
-- At last week's telcon, the WG discussed using IDREFs instead of generic
HREFs for representing graph edges in the SOAP encoding. Per their action
from that telcon, JK and MH have described the pro's and con's of using
IDREFS . This discussion will be time limited.
DavidF: Based on recent email discussions and our last telcon, we can
discuss the pro's and con's for IDREF and HREF proposed by Marc and Jacek,
or we can discuss which code (SOAP processor or otherwise) would process
external references. Which way does the WG want to take to move forward
with this issue?
??: We need an answer to: Why is HREF important, and better than IDREF?
That answer might help resolve the discussion.
Henrik: Describes the problems attempting to address here.
NoahM: Agree with HFN's assumptions but not his conclusion: It is not the
purpose of the SOAP spec to indicate how to process. The question is, why
are we doing this at all? SOAP started as RPC system and programs needed
structs / arrays. Underneath the covers is a graph model. If that is reason
-- constraint on design -- when use encoding in order to map to programming
space -- should be able to do this efficiently. External references might
be too much to require processors to handle.
Henrik: Soap encoding -- RPC represents one kind of graph. Not the
assumption that it is the ONLY use case. RDF example.
JacekK: There are issues with HREF (performance not withstanding), which do
not apply to IDREFS. Ref to Gudge's email Section 5 v. Schema: not all
applications need full power of XML and Schema, and SOAP encoding provides
a simpler mechanism, especially if used with IDREFs instead of HREF.
Henrik: With regard ease of implementation, within the context of W3C
(which use URIs) we will need a strong argument for why we wouldn't use
URIs. It might create discord with what else is going on in W3C.
NoahM: But taking thsi argument to the extreme, XML would be thrown out. We
are moving forward with XML, but not everything a link... Proposal:
Architecturally we have graph encoding that uses URIs, however there is a
subencoding when using RPC -- a subset of the encoding -- in which all the
URIs are local fragment identifiers.
Henrik: Thinks that this would work.
NoahM: Advantage: the local space is clearly a subset of the overall URI
Henrik: In this case, we do need refs, so why not use URIs?
DavidF: Summarising .... The proposal is for a SOAP encoding -- described
as graph -- whose edges are described using URIs, and we say there is a
SOAP encoding 'prime' that is used for the RPC mechanism.
NoahM: Lose closure to XML when moving to HREF???? Recommendation that
untyped -- push back from others.
???: Proposal to use SOAP 1.1 encoding and define a new one that uses
JacekK: I can't see both encodings being implemented in same number of
Gudge: What is the problem with saying "Our world is closed. You can put
HREF in your own encoding."
Many WG members concurred.
Chris: If we have two encodings, I would not want one to be a subset of
the other. URIs are distinct from IDREF.
NoahM: Let me clarify : a local referecnce such as "#foo" is similar to
ID/IDREF if you throw out the #.
Mark: Idea of two different ways of doing this doesn't feel right. Now
you have to implement two different encodings, and you still have to solve
all the issues listed under HREF column (in the HREF/IDREF summary).
DavidF: At this point, our choices are:
1) HREF vs. IDREF
2) Investigate "HREF-prime" in which local references are a
subset of HREF
DavidF takes non-binding straw-poll to determine which course to take.
No interest is epxressed in pursuing HREF-prime
DavidF: So now we decide between HREF and IDREF
Discussion on SOAP with Attachments.
DavidF: Can anyone not live with the IDREF proposal?
No one answers
DavidF: Can anyone not live with the HREF proposal?
No one answers.
DavidF: As no-one cannot live with either option, we need to choose one of
the two options. To make this choice, we will simply choose the option that
commands the greatest support.
No one objects to this procedure.
The Chair conducts an informal poll: 12 people support IDREF, 3 people
The Chair rules that IDREF represents the WG's consensus. (He also notes
that this does not resolve issue 170.)
(i) the basis for fault generation, specifically MUST, SHOULD or MAY (see
StuartW's summary  and ).
Discussion of issue 170.
JacekK: Argues that not being able to dereference a link MUST result in a
NoahM: Disagree with JacekK's conclusion. Clearly it is an error to have
an error in an ID/IDREF link. On the otherhand, it is a different matter to
say that a processor MUST fault. The processor must be able to detect a
fualt but what is the order of events? For example, a body has 5 parts
suppose processing first part indicates not to
process the other 3 or 4. MUST implies you have to fault if 3 or 4 has an
error. Saying MAY fault is sufficient to indicate a not very good message.
If MUST -- implies that all processing must be done, and we should give
discretion to processor.
?: I take this as an argument for SHOULD
JacekK: Notes that Noah's points weaken his MUST position to SHOULD.
NoahM: Need to clarify rules of what happens in case of fault.
Stuart: Processing model already handles this, I am concerned if we say any
more than that for special cases. Agree with MAY -- if MUST, then what is
the intended effect of a fault?
Henrik: Agree with MAY.
NoahM: Perhaps we have problem with processing model, perhaps we need to
clarify Faults during body processing -- at discretion of processor.
Encoding faults are the same, some vagueness applies.
Henrik: Need to be crisp on what conditions generate a fault.
DavidF: Please clarify, do you agree with Noah?
NoahM: I am in a different place than Henrik. The 1.2 draft describes what
to do for application, not for SOAP. It would be inconsistent with 1.2
design to define in SOAP itself. Possibly OK to define in the RPC section.
The specification describing SOAP processing defines how to handle faults.
That spec should say what should happen when processing the body.
Chris: Encoding and DataModel section may reference this, not SOAP
processing. SOAP is useful without the encoding.
NoahM: That depends on whether dealing with original concern or what
Stuart was addressing. There is a problem of where/when generate faults
during SOAP body processing.
Henrik: Move discussion to encoding section - agree.
DavidF: We are expanding the number of directions to consider. Would like
to take discussion back to email. Ask that Chris send an email to kick off
discussion on who is responsible for generating faults.
DavidF: Now move into 168, due to resolution to IDREF.
(ii) issue 168, type of referenced data .
NoahM: Proposal for typing of the nodes in the graph. Re: encoded XML
stream, the specification needs to add 'on the referenced resource'. The
whole paragraph needs to be rewritten, because we have switched to IDREF. I
recommend a single named attribute -- interpreted as IDREF, though it is
not an actual IDREF. The resources identified by that named attribute, may
be typed by xsi:type attribute (on the referenced resource).
DavidF: There appears to be a fair amount of overlap with resolution of
this issue and the IDREF story, so I think need to wait until have text in
hand for the IDREF resolution, and we should make sure that text handle
8. Issue 137, intermediaries relaying SOAP messages without modifying them
9. Issue 176
Review of existing action items
2001/11/07: Editors [Henrik]
Provide examples of encoding too! (by 2001/12/15 -> by EOW 2002/01/09)
Contact P3P and Xforms regarding their requirements
Incorportate requirements from RDF, UML, XML Encryption, ... in
Hunt down issue #98 (incorrectly labelled as #9 earlier)
Followup on QA
2001/12/05: HenrikN &DavidF
Follow up on links to requirements from external WGs by monday noon EST.
Partially done -- PENDING
2001/12/19: Issue list maintainers
Close issue 171, 173 with  and  (see agenda 19/12) (done for 171)
Send xmlp-comment to close issue 173 after receiving text from Jacek
Send his draft message to the TAG
Send mime type registration to IANA by EOW, and notify x-mime ML
Send mail asking whether people agree that issue 137 and 175 are dupes
Try to integrate JohnI's comments into the spec
DONE: Meeting - will send out note
Complete encryption scenarios and send them to xml-dist-app and
Report about schema type library on email
2002/01/09: MarcH, JacekK
Draft email about problem potentially solved by idrefs on issue 170 by
Send resolution email to close issue 40 with modified proposal fro RayW
Send resolution emails to xmlp-comments (3 of them) to close 117 144 and
Send resolution text for issue 47 (ETF text accepted)
Send resolution text for issue 164
Open new issue after closure of 174
Send resolution text to close issue 174
New Action items from this call
Followup with PaulD re: issue #98
Review xmlp-comments and report by end of week (2002/01/18).
Send note on Issue 12 closure to xmlp-comments
Send note on Issue 69 closure to xmlp-comments
Send note on Issue 131 closure to xmlp-comments
Send note on Issue 129 closure to xmlp-comments
Send email to XMLP list. Proposal for putting text into encoding
section regarding Agenda Item 7 (Issue 170).
To be completed within 2 days.
Generate text to be generated for IDREF resolution.
To be completed by next Wed in time for next telcon.
Make proposal for resolution of 168 as far as type.
To be completed by next Wed in time for next telecon.