Re: Detecting unbound options

Hash: SHA1

Norman Walsh writes:

> mozer <> writes:
>> Are you suggesting that we eventually end up needing a construct to
>> test if a variable is bounded ?
> No. After more thought, I'm suggesting that the concept of unbound
> options is a mistake. As a (SIGNIFICANT) convenience to users, and
> consistent with languages like XSLT, I think an option with no binding
> should get a default value.
> Since we've decided that variables and parameters must be strings
> in XProc 1.0, I propose the empty string as that default value.
> Effectively "" becomes the default default for options.

Gee, I'm still not happy with that idea.  There are lots of cases
where not specifying a value is importantly different from specifying
the empty string.  A quick look at our spec. finds

  p:directory-list: include-filter, exclude-filter
  [serialisation steps]: doctype-public, doctype-system, undeclare-prefixes,
  p:make-absolute-uris: base-uri
  p:namespace-rename: from, to
  p:unescape-markup: namespace, encoding, charset
  p:wrap(-sequence): group-adjacent
  p:xslt: initial-mode, template-name, output-base-uri, version
  p:exec: [lots]
  p:hash: version
  p:uuid: version
  p:xsl-formatter: content-type

as non-required options with no default.

For at least include-filter, base-uri, group-adjacent and
output-base-uri the empty string seems to be either the wrong default
or a legitimate value distinct from [not specified]. . .
- -- 
       Henry S. Thompson, School of Informatics, University of Edinburgh
                         Half-time member of W3C Team
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: (44) 131 651-1426, e-mail:
[mail really from me _always_ has this .sig -- mail without it is forged spam]
Version: GnuPG v1.2.6 (GNU/Linux)


Received on Wednesday, 27 May 2009 12:09:52 UTC