Minutes of Encoding Task Force, 24 January 2002.


  1. Updated list of action items:
  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.