Re: Remarks on W3C Editor's Draft 6 August 2007

/ Jeni Tennison <jeni@jenitennison.com> was heard to say:
| Norman Walsh wrote:
|> / Innovimax SARL <innovimax@gmail.com> was heard to say:
|> | On 8/16/07, Norman Walsh <ndw@nwalsh.com> wrote:
|> |> / Jeni Tennison <jeni@jenitennison.com> was heard to say:
|> |> | I think we should switch to using 'true'/'false' everywhere for option
|> |> | values, since that's what boolean true/false get converted to as
|> |> | strings. If we do that, it makes sense (to me) to switch to true/false
|> |> | everywhere.
|> |>
|> |> We agreed to this on the call, but as I set out to implement it, it became
|> |> pretty clear to me that using xsd:boolean was both easier to specify
|> |> and consistent with other types, so I did that instead.
|> |
|> | But I fear we will have to choose our way for "inherited from
|> | Serialisation Spec" options (especially standalone and
|> | omit-declaration)
|>
|> Bleh. Maybe those remain yes/no?
|
| We could use true/false and say that they map on to yes/no as defined
| in the serialisation spec. Or allow both in this special case. I
| prefer either of these to *only* allowing yes/no.

True. It's our surface syntax. I suggest we go with true/false just like
everywhere else and note that our true = their yes and our false = their no.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | The greatest of all secrets is knowing
http://nwalsh.com/            | how to reduce the force of
                              | envy.--Cardinal De Retz