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

Peter,

Unfortunately, as you surmise, I doubt we would be able to make
changes such as you suggest that would make existing valid XSL
stylesheets invalid, especially for no visible benefit to the
end users.

As I indicated, the XSL FO subgroup did spend a fair amount of
time trying to weigh the various options and decided on this
compromise.  Realizing that no solution is perfect, I think we
did come up with the most workable compromise.  I hope you find
it acceptable.

paul

At 10:55 2002 09 27 +1000, Peter B. West wrote:

>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?"