Present
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
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.
Marc: data model talks about objects, how about something else? (nodes, values) Henrik will do the editorial change from "object" to "node".
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.