Minutes of Encoding Task Force, 17 January 2002.

Present

• Jacek Kopecky (scribe/chair)
• David Fallside
• Marc Hadley

1. Updated list of action items:
   • HFN will propose changes to spec and primer to resolve ed issue #17
   • HFN to propose resolution for ed issue #55, will contact PaulC and JohnI to determine history of this action
   • DF contact Schema experts re issue #163
   • DF to ping RDF/UML re issue #29
   • JK contact Asir about i167 - whether it still stands and what it actually means
   • MH write a response to Gudge's email; propose to remove Schema from Encoding examples, add C-style code; in connection with issue 17
   • JK propose to keep status-quo on issue 168, explicitly ask Noah to reply with points from yesterdays WG telcon
   • JK propose 170 with "when dereferencing"
   • MH set up the next telcon, same time same place
   • JK point again to issue 177 opened just after the end-of-year break
2. Discussion on Gudge's email

   Marc: maybe we can use a pseudocode in our Encoding examples
   Jack: WSDL uses XML Schema
   David: why only one style of examples?
   [David had to leave early, only Marc and Jack present now]
   Marc: two options: pseudo-C, or pseudo-C + schema
   Jack: if we tackle Schema description of our data, we should formally specify
         the mapping from our data model to Schema descriptions and back.
   
   Consensus was that we only have the pseudocode, that we add XSI:type attributes
   in the examples, that we leave one simple example with an associated schema to
   demonstrate that XSI:type is not mandatory
   	

3. XML Schema enumerations and lists:

   Jack: we talk about XML Schema simple-type enumerations, we don't talk about
         simple-type lists. Feels inconsistent. (Lists are handled by arrays in
         SOAP.)
   Marc: many programming languages have enums, so we specify them.
   
   OK, no issue here, move along.
   	

4. Issue 168: untyped data?

   Jack: Noah had some valid points in yesterday's WG telcon that could lead us to
         removing the requirement that every value be typed.
   
   Consensus was that we propose to close 168 by keeping status quo, and we ask
   Noah to explain his points (maybe they are an other issue).
   	

5. Issue 170: referencing missing data

   Jack: we have the MUST/SHOULD/MAY fault in such a case choice here.
   Marc: Since we assumed the "close-world" approach to SOAP data model with our
         accepting IDREFs, any error on deserialization is a fault. On the other
         hand, MUST seems to require that the processor check the entire message.
   Jack: the original use of MUST in my proposal was in an important context:
         ...when deserialization encounters a broken link, it MUST fault...
   Jack: so it seems MUST is appropriate here
   Marc agreed
   
   We will propose to have "MUST when deserialization encounters a broken link"
   which weakens the MUST considerably. Other issues with ordering of faults etc.
   can pop up on us, as discussed on yesterday's WG telcon.
   	

6. Issue 177: missing accessors same as NULL?

   We agreed that the proposed two options are the ones that we have.
   Jack: there was no discussion on the original post, so maybe let's just forward
         it to the WG?
   Marc: it was just after the xmas break, it might have got lost.
   
   Jack will try to elicit some discussion again on dist-app.