W3C home > Mailing lists > Public > public-xml-processing-model-wg@w3.org > August 2008

Re: p:option not required without default value

From: Jeni Tennison <jeni@jenitennison.com>
Date: Fri, 29 Aug 2008 21:23:32 +0100
Message-Id: <BB2D5873-C6A5-40D0-9F97-F73EAD4EAA47@jenitennison.com>
To: public-xml-processing-model-wg WG <public-xml-processing-model-wg@w3.org>

On 29 Aug 2008, at 18:41, Innovimax SARL wrote:
> 1) We forbid to have an option that has no default and is not bound
> 2) We propose a default value
>  2a) A default value that generate an error (which seems impossible
> since string() always succeed)
>  2b) The default is the empty string
> If we go with 1), then we should get rid of @required, since if you
> provide a default value, it cannot be required, and if there is no
> @select, then it is required
> If we go 2) then we stick to XSLT 1.0 and 2.0 behaviour (for good or  
> bad)

I think we will have more flexibility in the future (should we want to  
provide a good default default value such as an empty sequence, when/ 
if options are allowed to take values other than strings) if we don't  
fix a default default of an empty string.

Looking through the required steps, there are quite a few optional,  
"undefaulted" options. Most of them could be given a reasonable  
default but an empty string wouldn't be legal (eg 'node()|@*' would be  
reasonable for match patterns, but an empty string wouldn't be legal).

There are a few where it's harder. For example, the default value of  
'media-type' on p:escape-markup is dependent on the 'method'. Perhaps  
that just means it should be declared (after the declaration of the  
'method' option) as:

   <p:option name="media-type"
     select="if ($method = 'xml') then 'application/xml'
             else if ($method = 'xhtml') then 'application/xhtml+xml'
             else if ($method = 'html') then 'text/html'
             else 'text/plain'" />

However, putting logic in the default value of an option doesn't make  
sense when you're declaring an atomic step, where presumably the  
option defaults are defined by the processor rather than the step  
declaration. So what about:

   * in the declaration of an atomic step
     * the required attribute is used to indicate whether the option  
is required or not
     * the select attribute may be used to declare a default value; if  
it's not specified the default is implementation-defined

   * in the declaration of a pipeline
     * if the select attribute is present, it's used as a default  
value (and required must be 'no')
     * if the select attribute is not present, required must be 'yes',  
and defaults to that value if it's not specified


Jeni Tennison
Received on Friday, 29 August 2008 20:24:10 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:41:40 UTC