W3C XML Protocol Working Group teleconference, 16 January 2002

Minutes of XML Protocol telcon, 16 January 2002.

1. Roll call

Present 29/22 Excused Regrets Absent

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


Minutes approved.

4. Review action items

5. Status reports


-- Primer
 o nothing to report

-- Spec
 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.

-- TBTF
 o they are identifying remaining pieces of work and who is responsible for
these items
 o some TBTF issues are in Agenda #6

-- ETF
 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 [6]. 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
week.

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 [7]

-- 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 [8]. 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
usage.
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
IDREFs.
JacekK: I can't see both encodings being implemented in same number of
cases.
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
support HREF.
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 [9] and [10]).

Discussion of issue 170.
JacekK: Argues that not being able to dereference a link MUST result in a
fault.
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?
Henrik: Yes
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 [15].

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
this case.

8. Issue 137, intermediaries relaying SOAP messages without modifying them

[18]
POSTPONED

9. Issue 176

POSTPONED

Review of existing action items

2001/11/07: Editors [Henrik]
  Provide examples of encoding too! (by 2001/12/15 -> by EOW 2002/01/09)
  PENDING
2001/11/27: ChrisF
  Contact P3P and Xforms regarding their requirements
  DONE
2001/11/27: Editors
  Incorportate requirements from RDF, UML, XML Encryption, ... in
requirements doc
  PENDING
2001/11/29: PaulD
  Hunt down issue #98 (incorrectly labelled as #9 earlier)
2001/11/29: HugoH
  Followup on QA
  PENDING
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 [7] and [8] (see agenda 19/12) (done for 171)
  DONE
2001/12/19: Yves
  Send xmlp-comment to close issue 173 after receiving text from Jacek
  DONE
2002/01/09: MarkB
  Send his draft message to the TAG
  DONE
2002/01/09: MarcB
  Send mime type registration to IANA by EOW, and notify x-mime ML
  DONE
2002/01/09: HenrikN
  Send mail asking whether people agree that issue 137 and 175 are dupes
  DONE
2002/01/09: Editors
  Try to integrate JohnI's comments into the spec
  DONE: Meeting - will send out note
2002/01/09: DavidO
  Complete encryption scenarios and send them to xml-dist-app and
xml-encryption
  PENDING
2002/01/09: DavidF
  Report about schema type library on email
  PENDING
2002/01/09: MarcH, JacekK
  Draft email about problem potentially solved by idrefs on issue 170 by
EOW
  DONE
2002/01/09: DavidF
  Send resolution email to close issue 40 with modified proposal fro RayW
  DONE
2002/01/09: JacekK
  Send resolution emails to xmlp-comments (3 of them) to close 117 144 and
161
  DONE
2002/01/09: MarcB
  Send resolution text for issue 47 (ETF text accepted)
  DONE
2002/01/09: JacekK
  Send resolution text for issue 164
  DONE
2002/01/09: NoahM
  Open new issue after closure of 174
  DONE
2002/01/09: NoahM
  Send resolution text to close issue 174
  DONE

New Action items from this call

2002/01/16: MartinG
  Followup with PaulD re: issue #98
2002/01/16: MartinG
  Review xmlp-comments and report by end of week (2002/01/18).
2002/01/16: ChrisF
  Send note on Issue 12 closure to xmlp-comments
2002/01/16: DavidF
  Send note on Issue 69 closure to xmlp-comments
2002/01/16: NoahM
  Send note on Issue 131 closure to xmlp-comments
2002/01/16: JacekK
  Send note on Issue 129 closure to xmlp-comments
2002/01/16: Chris
  Send email to XMLP list.  Proposal for putting text into encoding
  section regarding Agenda Item 7 (Issue 170).
  To be completed within 2 days.
2002/01/16: JacekK/MarcH
  Generate text to be generated for IDREF resolution.
  To be completed by next Wed in time for next telcon.
2002/01/16: JacekK/MarcH
  Make proposal for resolution of 168 as far as type.
  To be completed by next Wed in time for next telecon.