Fopdevs, Another response from the editors. The original message was sent on 2001/11/28. This answer, while interesting, addresses neither of the specifics of my question. As for the disposition, I am simply appalled by it, but I would like some comments before I respond.
Peter -------- Original Message -------- Subject: Regarding your comment about on xsl-editors Date: Wed, 18 Sep 2002 18:10:28 -0500 From: Paul Grosso <[EMAIL PROTECTED]> To: "Peter B. West" <[EMAIL PROTECTED]> CC: [EMAIL PROTECTED] 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 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 datatype in section 5.11: Given the allowable Expression Value Conversions (section 5.9.12), a property value of type must be a quoted value, an NCName, or a expression that evaluates to a ; 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 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]