Re: Regarding your comment about <string> on xsl-editors

Paul,

Thank you for your response.  I say this with a sense of complete 
hopelessness, but would it not be better to fix XSLT than to break 
XSLFO?  I know there will be wailing and gnashing of teeth, and there 
will probably be non-conforming implementations.  However, XSLT 2.0 has 
not been finalised yet, so the opportunity exists to fix it.  The format 
attribute value is surely a literal string, so why not express it that 
way?  Such a decision would flow on to XSLFO, and the previous situation 
would remain correct.  Current non-conforming XSLFO implementations 
would be in no worse situation, and some consistency would be achieved 
across the board.

While we're at it, could you possibly replace <string> in the data types 
description with <literal>, and in those situations where the NCName to 
string conversion may be invoked, simply allow <literal>|<name>?

In the case of font names like "Times New Roman", it may be necessary to 
allow something like NCNAMES.  I'm sorry that is a bit vague.  I haven't 
thought through that particular situation (which was one of the triggers 
for my original post).

Peter


Paul Grosso wrote:
> Peter,
> 
> Thank you for your comment to [email protected] archived at
> http://lists.w3.org/Archives/Public/xsl-editors/2001OctDec/0043
> 
> This question of yours started quite a discussion.  Specifically,
> section 5.9.12 Expression Value Conversions allows for the automatic
> conversion of NCNames to strings.  This allows, for example, one
> to say font-family="Arial".  The expression evaluator should evaluate
> the property value to be an NCName and then realize the datatype of
> the property is <string> and do the automatic conversion.
> 
> However, we note that something like format="1" would not, in fact,
> work, since 1 is not an NCName.  Therefore, format="1" would actually
> be an error.  (The correct syntax would have to be format="'1'".)
> There is no way around this, since format="substring('123',1,1)"
> would be a valid assignment, and format="2-1", while not a valid
> assignment (because it does not evaluate to a string or NCName),
> should get evaluated into the integer 1.  
> 
> While we could clarify that something like format="1" is invalid,
> the XSL WG figured that no implementor would implement that.  (All
> implementations currently accept format="1", and no one expects
> they will stop doing so.)  So we wanted to find a compromise that,
> while respecting the XSL expression language, didn't make all
> existing implementations non-compliant.  This led us to say that,
> while such is an error, an implementation may recover from this 
> by treating the value as a string.  (It may signal an error and
> halt, but we doubt may implementations will do that.  It may also
> give a warning and continue, or just recover silently.)
> 
> Still more interesting is format="1." which would get evaluated 
> into the integer 1 and, if then just silently converted to a string,
> would end up being equivalent to format="'1'" instead of format="'1.'"
> as probably intended.  This led us to our final solution.
> 
> Therefore, the following is our disposition of your above comment:
> 
> ---
> 
> We DECIDED to add the following Note to the description of the <string> 
> datatype in section 5.11:
> 
>   Given the allowable Expression Value Conversions (section 5.9.12),
>   a property value of type <string> must be a quoted value, an NCName,
>   or a expression that evaluates to a <string>; anything else (e.g.,
>   an integer) is an error.  An implementation may recover from this
>   error by treating the unevaluated property value as a string.
> 
> ---
> 
> Please Reply (cc-ing [email protected]) if you wish to make
> an objection to our resolution.
> 
> Thank you for your interest in XSL.
> 
> Paul Grosso for the XSL FO Subgroup of the XSL WG 
> 

-- 
Peter B. West  [email protected]  http://www.powerup.com.au/~pbwest/
"Lord, to whom shall we go?"