-------- Original Message -------- Subject: Re: Regarding your comment about <string> on xsl-editors Date: Fri, 27 Sep 2002 14:00:53 -0500 From: Paul Grosso <[EMAIL PROTECTED]> To: "Peter B. West" <[EMAIL PROTECTED]> CC: xsl-editors <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]>
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. -- Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/ "Lord, to whom shall we go?" --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
