W3C home > Mailing lists > Public > xproc-dev@w3.org > May 2009

Re: Detecting unbound options

From: Dave Pawson <dave.pawson@gmail.com>
Date: Wed, 27 May 2009 13:42:53 +0100
Message-ID: <711a73df0905270542r52bae75ft5f91ab4fb727e0d0@mail.gmail.com>
To: XProc Dev <xproc-dev@w3.org>
2009/5/27 Norman Walsh <ndw@nwalsh.com>:
> "Henry S. Thompson" <ht@inf.ed.ac.uk> writes:
>> 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.

Again learning from Apache ant.
I test for both unspecified and no value specified.
Note, I'm talking about variables here.
Please disregard if you're only thinking of options/params etc.



> I don't think all of those are problematic. Options that aren't
> strings (undeclare-prefixes) or are QNames (initial-mode, template-name)
> or that don't have a meaningful empty-string value (doctype-public,
> media-type) are all ok.
>
> But you're right that it would be a problem for some (base-uri, from,
> to, ...)
>
> Yuck! But can we really live with this...


What of your file utilities?
create file ${varName}

would leave me with ??? What? A file named ${varName} ?

How about a configuration option to report unspecified variables?
I'd certainly like to have xproc fall over 'variable XYZ unspecified'.

regards




-- 
Dave Pawson
XSLT XSL-FO FAQ.
Docbook FAQ.
http://www.dpawson.co.uk
Received on Wednesday, 27 May 2009 12:43:25 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 27 May 2009 12:43:25 GMT