W3C home > Mailing lists > Public > xsl-editors@w3.org > July to September 2002

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

From: Paul Grosso <pgrosso@arbortext.com>
Date: Fri, 27 Sep 2002 14:00:53 -0500
Message-Id: <>
To: "Peter B. West" <pbwest@powerup.com.au>
Cc: xsl-editors <xsl-editors@w3.org>


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.


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

>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).
>Paul Grosso wrote:
>>Thank you for your comment to xsl-editors@w3.org archived at
>>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 xsl-editors@w3.org) 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  pbwest@powerup.com.au  http://www.powerup.com.au/~pbwest/
>"Lord, to whom shall we go?"
Received on Friday, 27 September 2002 15:05:51 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:44:22 UTC