W3C XML Protocol Working Group teleconference, 25 July 2001

XMLP WG telcon, July 25, 2001

1. Roll call

Present 33/27 Excused Regrets Absent

2. Agenda review

   No other items.

4. Review action items

   1. for David Clay. Marked as closed because it is covered by
      other topics.

   2. for Hugo. Document sent this morning.

   3. for Paul C. Outstanding issue.

   4. for Nilo. On the agenda today so marked as closed.

   5. for Glen D.
      [Glen] This was to do what Chris ended up doing.
      [David] So we can close this item.
      [Glen] We also need a larger scale version of what an
             infoset is to be expanded out to the group.

   6. for Gudge.
      [Gudge] Think this is done and the results were sent to Chair.
      [David] Marked as closed and will appear in next week's agenda.

   7. for Glen D.
      [David] On agenda for today so this item is discharged.

6. Review proposed resolutions to issues

   Issue 24. Proposed resolution sent to eric@microsoft. Chair will
             continue to investigate.

   Issue 99. Proposed resolution sent from Glen. Is this acceptable?
             No responses so closed with that resolution text.

   Issue 100. Glen looked through the specification text and sent
              a summary via email.

   [Glen]  In summary, the specification is unclear on this issue.
           We can decided the security of the error. Secondly, if we
           if we don't throw an error then we can consider Noah's
           suggestion of a 'mustHappen' attribute.
   [MarkJ] At Dinard we discussed ordering and mustHappen. I thought
           that the algorithm for processing headers was extensible
           enough to handle this.
   [Glen] We could mention in that space that we have extensions for
          people to add that capability.
   [David] Do we need to design this?
   [Glen] Maybe we don't have to design this then.
   [Noah] A semi-minimalist approach sounds good. But I prefer not to
          have optional behavior. I would specifically suggest that if
          the specification is unclear then it must be made clear that
          it is not specified. Also we don't standardize the
          mustHappen semantics because they are related to larger
          issues. An example is multicast. What does mustHappen mean
          for that case?
   [Chris] From the RPC call today we talked about 'best-practices' or
           'standard extensions' as another separate specification.
   [David] I am hearing 1) we should make it more explicit that it
           is not necessary to throw an error. and 2) Do not
           investigate creating a mustHappen attribute.
   [Noah] Need clarification of 'is not necessary'.
   [David] We need clarification of that semantic.
   [Glen] mustUnderstand targeted at an endpoint needs to check
          that all the intermediate mustUnderstands were processed
          that were addressed to intermediate nodes.
   [Noah] We disagree but shouldn't spend time on this.
   [David] We need a proposal. I would like to hear more exact
           terminology for clarifying that part of the specification.
           Noah - you would rather not say that the ultimate receiver
           may throw a mustUnderstand error if it receives a
           mustUnderstand header which is not targeted at it?
   [Glen] It does not say you should do it, it doesn't say you
          shouldn't do it.
   [Noah] If we don't say do it, then don't test for interoperability
          based on it.
   [David] Specification covers normative behavior.
   [Glen] The Soap Builders community is concerned about this
          issue. It should be described in the description of the
          process model.
   [Chris] The issue is for people building generic SOAP engines
           versus applications. Noah is saying that we don't want to
           preclude mustUnderstand blocks never reaching the correct
           actors. From the SOAP processing perspective, if it throws
           an exception then that prevents applications that don't
           care.
   [Noah] Compromise text. Note that as a consequence of these rules
          that it is possible for a message to reach an endpoint with
          headers that are mustUnderstand that have not been
          processed. This situation can arise. It is not an error and
          does not result in an error according to this
          specification, but it is possible to have extensions to
          define this as a fault.
   [Doug] Glen is suggesting the client does not know if endpoint is
          throwing an error. Noah's text is much clearer what the
          endpoint will do.
   [Glen] In the general case it is a client issue.
   [David] Glen and Noah to come up with some wording for the
           specification. No suggestion for designing a mustHappen
           mechanism?
   [Chris] If we add wording such as Noah's, then developers will be
           scratching their heads. It is possible that an extension
           could be widely accepted though.
   [Doug] I would like us to define this especially if the
          specification says we throw an exception without the
          extension.
   [Noah] Let's do it better or not at all.
   [Chuck] How about making it non-normative?
   [David] We have an extension mechanism. If we put a note in
           explaining a specific case, then it ballooned out to
           designing a mechanism. We do not have time to do this in
           general.
   [?] I agree but this is a special case. It is perfectly appropriate
       to defined a standard extension.
   [Glenn] I will send out a proposal. But I won't say if it belongs
           in the specification or not.
   [?] Could be in the primer? Example from the schema primer as a
       non-normative location.
   [Jake] Similar to correlation ID extension? We are making a
          correlation ID extension?
   [David] It is being worked up by the TF and will be put up in front
           of the WG. It will not be put out normatively. Glen and
           Noah to write up a note to go into the specification.
   [Glen] Happy to build up the beginning of this work.


   Issue 102. Jacek, you put forward a resolution proposal.

   [Jacek] I went through the specification. The specification is
           careful not to say where the fault goes except for the RPC
           case. Responsibility of the message patterns to specify
           this. The specification needs to say this: The
           responsibility of specifying where faults come and go is up
           to the message patterns.
   [Chris] Not clear that a message pattern is not necessarily bound
           to a transport protocol.
   [Jacek] Does not have to be bound, but messages from node to node.
   [Noah] If I can clarify. SOAP 1.1 has half-baked message
          patterns. When you use SOAP over HTTP, responses go across
          HTTP responses. SOAP 1.1 doesn't say much about other
          bindings. What is a response? It only says this a bout
          RPC. Better off with a lightweight but first class message
          pattern. Start with one-way and request/response, followed
          by the relationship with the binding.

          When I invent a new binding, required to define which
          message patterns it supports.

          This is all background to support Jacek's response.
    [Mark] We have been discussing this in the TBTF. It is attached to
           transport?
    [Noah] My thoughts are that it is detached but needs to be
           architected to use the facilities of the transport
           efficiently.
    [David] Proposed resolution of 102 presupposes something that does
            not exist in the specification so it is premature to
            accept this resolution. But we can take this as a signal
            to the TBTF that a formal message pattern definition is
            needed. Is this reasonable?

    (General agreement)

    [David] TBTF will take up message exchange patterns and we will
            leave 102 until the TF gets back.


    Issue 106. Ordering issues of mustUnderstand in context of
               multiple headers. We have a proposal. No comments from
               WG, so chair judges that we can close 106 with the text
               in the proposal.

    Issue 107. Eric made a proposal for wrapping up 107. 4
               subproposals and 1 outstanding issue.

               First proposal is a minor change to Section 4.2. The
               commentator in email agreed. Any disagreement? No
               comment was made, so chair judges the WG has decided
               to make the change.

               Suggestion 2 and 3 covered by resolution that deals
               with overlap in the specification. Eric agrees to that
               response. Question to the Editors, is there a proposal
               for solving that overlap?
    [Editor] Need editing time and go ahead from the WG on the new
             section.
    [David] Can the editors give us a date?
    [Editor] Before the next telcon.
    [David] That's entirely acceptable. Number 4, there was a
            disagreement. The commentator felt it was already covered.
    [Eric] Judgement call. I also felt that it was already covered but
           if the WG wanted more, that was my proposal.
    [David] No, WG desires to drop the suggestion.
    [Eric] Fine by me.
    [David] Open issue of what is a SOAP Application. Is the one line
            in the specification sufficient?
    [Eric] Stuart had a response which included a definition of a SOAP
           application.
    [David] Is your proposal to put in a definition above and beyond
            how it is currently called out?
    [Eric] Difference between application and a SOAP node is the
           issue. Do we need two terms? Or are they different?
    [David] We will need a proposal for what that definition would
            look like.
    [Eric] Couldn't see any differences except that a SOAP Application
           could span multiple SOAP nodes.
    [David] Is that covered in Stuart's note?
            Eric and Stuart to work on a proposal.

7. Review Infoset version of spec

   Five specific questions/issues were raised in the text of the Infoset
   version. Any comments?

   [Mark] General point. If we go down the infoset route, we need to
          also go down the primer route.
   [?] Could we add more examples to the specification to cover this?
   [Gudge] Prefer the Infoset to be descriptive and the primer to have
           the examples.

   (Discussion on defaulting values from schemas followed)

   [Chris] It is compatible, we just need to specify the attribute
           information item properly.
   [Gudge] Might have been defaulted in by schema processing.
   [Chris] Are we requiring it to be schema processed? It cannot be
           DTD processed.
   [Gudge] Why can't it be defaulted by a DTD? Seems strange to say
           that you must have it in the Instance and it cannot be
           defaulted in. I can go either way. Specification can say
           cannot be defaulted in or it can say that we don't care.
   [Noah] SOAP core mechanisms depend on schema processing? SOAP 1.1
          is not dependent on schema processing.
   [Gudge] The sender must put them in there.

   (Lots of agreement to maintain status quo)

   [Chris] Need to make it explicit that attributes added by
           application can never be defaulted by a DTD. And if an
           application expects attributes to default from a schema, be
           aware that processors are not required to do schema
           validation.
   [Noah] Schema defaulting adds new properties. Never change existing
          items.
   [David] Chris will write a proposal for wording on application
           defined attributes.

           When we have these modifications to the Infoset and the
           Infoset editor's copy, is that sufficient changes to put out as
           a new Working Draft?

   (General agreement)

8. Review proposal for Primer

   Deferred to next week.


End of call.