Regarding your comment about <string> on xsl-editors

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