[Fwd: Regarding your comment about <string> on xsl-editors]

 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 <pgrosso@xxxxxxxxxxxxx>
To: "Peter B. West" <pbwest@xxxxxxxxxxxxxx>
CC: xsl-editors@xxxxxx



Peter,

Thank you for your comment to xsl-editors@xxxxxx 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 xsl-editors@xxxxxx) 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