W3C XML Protocol Working Group teleconference, 15 August 2001

1. Roll call

Present 34/29 Excused Regrets Absent

2. Agenda review

    1) May need to defer discussion of item 107 for next week
    2) Deadline earlier for Sept F2F registration -- now Aug 31
    3) Question of whether calls may extend to 120 minutes;
       discussion but voice response suggests this is OK

3. Minutes of 8-AUG-2001 approved

4. Action Items

  1. Issue 30 -- There is now sufficient information to proceed with forming a resolution on the issue
  2. Discussion of the must-happen proposal -- this excellent idea is perhaps beyond the scope of the WG, and this may be on the 22-AUG-2001 call
  3. Editors have considered the Infoset, Martin and Noah proposals. Are extensive rewrites needed for section five? Cover again on item seven
  4. Done
  5. Done
  6. RPCTF -- Done
  7. Object&Method terms in RPC (i42) -- Done
  8. Jacek+Editors -- New section 7.3 requires WG and discussion on the 22-AUG-2001 call, and remains open
  9. Done
  10. Done
  11. Done

5. Reports

    (i) Outline & discussion of proposal from Editor's for new
        documentation structure (Marc)
       A) a. Primer -- Contents sent by email
          b. Pt. I  -- Describes everything apart from a concrete binding.

             Compliance with all of Part One defines SOAP. Non-compliance
             is non-SOAP. Tentative title is "Core Message Framework".
             Contents:
             i.   Current document sections 1, 2, 3 and four
             ii.  New sections (to be written) with transport binding
                  framework
             iii. New sections (to be written) with references,
                  acknowledgements, transitions and change items
          c. Pt. II -- Standard the binding definitions and formal naming
             that Soap deployments should use when suitable. No deviation is
             permitted in usage of the SOAP bindings naming, although you
             may define private bindings if you prefer to. Discussion needed
             on the tentative title of "Normative Extensions".
             Contents:
             i.   New intro
             ii.  New (model, soap encoding, rpc)
             iii. Current document section five (soap encoding)
             iv.  Current document section seven (rpc)
             v.   Current document section six (http binding)
       B) Open questions include:
             i.   What is core, what is extension, what is mandatory, etc.
             ii.  What are scope and effect of header-triggered modifications?
             iii. What are conformance requirements for part I and part II

    (ii) Report from Transport Binding Task Force (Noah)
       A) About ten people with smaller working group. Roughing framework of
          what is available to the binding, and how to define binding 
          scenarios.
       B) Claimed this forms "sort of a distributed state machine" but no
          discussion of its formal properties as a state machine
       C) URI / binding interactions -- can binding ever define the URI?
       D) Binding task force has schedule concerns regarding the F2F, and
          agrees to provide "maximum utility in time for the formal F2F
          window" and will consider additions if more material is needed

    (iii) Report from RPC Task Force (Henrik)
       A) Further discussion of specific answers appears in section seven,
          below
       B) Four items discussed in conference calls this week; see email for
          detail
          i.   Framework properties -- what is the relationship between the
               SOAP data model and SOAP encoding for RPC with respect to other 
               systems', and may they use different encoding? Are such encoding
               independent of our model?
          ii.  What is encoding of the RPC return value, and what may the 
               value consist of?  Is this always the first item in a stream?
          iii. Clarification of terms "object" and "method"
          iv.  Draft has no need to define "object" since it is huge and
               out-of-scope
       B) Questions include: what is our purview regarding definition of the
          graph data model (who can define/redefine this), and the extend
          the model should consider RPC encodability and performance.  
          Issue 70/16 raises this and related issues. This should be a
          separate task force and is deferred to item seven below

6. Infoset and application-defined attributes (ChrisF)

       A) Discussion of defaults and schema validation
          i.   Defaults -- rules and mechanisms for the definition and recovery
               of "defaults"
          ii.  Schema Validation -- Schema validation is not mandatory.
               This precludes recovery of default [fields and] values through
               a mechanism of schema validation
          iii. A default attribute or value cannot be dropped.  Processors
               may give instance values but cannot change a default.
               Equivalently, "when an attribute is present it must always be
               provided in the serialization, but when must-understand=false
               it may be omitted"
          iv.  An application processor may follow the XP lead and not
               mandate schema validation. This does not preclude the
               requirement or deployment of processors with schema validation
       B) Editor copy will be reviewed after distribution of a new standard
          text

7. Issue 78/16

       A) Multiple issues including related to the RPC task force
          i.  Reuse of RPC Encoding -- the potential reuse of RPC encoding
              may encourage capabilities without degradation to the RPC data
              model and serialization
          ii. Invariance of RPC Encoding --  The RPC encoding is invariant.
              RPC MUST NOT signals or modifies the RPC encoding. RPC defines 
              the mandatory encoding without recourse to "on the wire"
              identification as RPC. This invariance does not preclude
              processor-specific data models and serialization, yet such
              substation encoding never redefine the RPC encoding

8. Response on XML Schema WG's base64 proposal

        Issue not covered due to lack of time.