Minutes of Encoding Task Force, 24 January 2002.

Present

• Jacek Kopecky (scribe/chair)
• Henrik Frystyk Nielsen
• 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 to write the proposal for 168 that if a receiver cannot get the type, it MAY fault with the subcode enc:UntypedValue
   • HFN to change the "object" to "node" in data model text
   • HFN to summarize the two options for solving 177, ETF prefers removing the distinction; for WG's consideration, CC it to DavidF so he can add it to the agenda
2. Discussion on when the next telcon should be

   In the beginning of the telcon, Asir hopped in to say when he
   _could_ attend the telcons, then he had to run.
   
   The ETF decides to have the next telcon on Mon 1/28, at 8am PST,
   4pm GMT, 5pm CET
   
   Henrik will chair and scribe and set it up
   	

3. Continuing discussion on 168 after yesterday's WG telcon

   Jacek: three options -
          1) everything is typed, untyped is an error
          2) everything is typed, untyped is the default type
          3) not everything is typed
   
   Jacek: I prefer 1
   
   Henrik: refs can reference anything, we should not require or
   default the type
   
   Marc: our data model is quite closed, our encoding rule no. 2
   mandates that every node be typed
   
   Marc:  keep status quo
   
   Henrik: +1
   
   Jacek: ok, what does receiver do when not validating, and not
   getting type otherwise?
   
   Henrik: do we have to say anything?
   
   Henrik: if receiver cannot get the type, it MAY fault with the
   subcode enc:UntypedValue
   
   Marc: details about the failure?
   
   Henrik: in detail element, implementation dependent
   
   Henrik's proposal will be formulated as the proposal of the ETF.
   
   	

4. The word "object" in the data model.

   Marc: data model talks about objects, how about something else?
   (nodes, values)
   
   Henrik will do the editorial change from "object" to "node".
   
   	

5. Discussion on 177

   Jacek: the repost resulted in a bit of discussion between Jacek
          and Rich Salz: "default" vs "unspecified" in the section
          option. Settled on "unspecified or possibly an
          application-supplied default"
   
   Jacek: Are these the two options? (from the discussion it
          seems so) Which do we pick? Or do we go to the WG with
          these two options (and maybe a slight preference for one of
          them) ?
   
   The Question: Are NULL and default the same or not?
   
   Rule no. 9 makes the distinction, but combined with section 3.5 it
   seems to not make the distinction.
   
   Two options again: 
   1) rephrase rule 9 and section 3.5 to keep the distinction
   2) rephrase rule 9 to remove the distinction
   
   The ETF will propose that the WG discuss these options, the ETF
   suggests removing the distinction.