Regarding your comment about <string> on xsl-editors

Peter,

Thank you for your comment to xsl-editors@w3.org 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 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

Received on Wednesday, 18 September 2002 19:11:12 UTC