-------- Original Message -------- Subject: Re: Regarding your comment about <string> on xsl-editors Date: Fri, 27 Sep 2002 10:55:28 +1000 From: "Peter B. West" <[EMAIL PROTECTED]> To: Paul Grosso <[EMAIL PROTECTED]> CC: xsl-editors <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]>
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?" --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
