Re: [xslt] Problem with variables



Richard Jinks wrote:

> Essentially, the Java1.1 spec doesn't strictly define how the percent is to
> be used -
> it doesn't cover the position of the %, what to do if there are multiple %s,
> etc.

While implementing this functionality I asked xsl-editors@w3.org for
clarification on this issue, but never received any answer. Instead
William Brack and I decided to simulate Java behaviour where feasible.

The description of format-string() in the XSLT specification is rather
poor. As many of these issues pops up here from time to time, I will
list the problems (at least those that I can recall right now) that
we've encountered during implementation and our solutions. These
decisions have not been posted publicly yet as they predates this
mailing-list. I don't know if the mentioned solutions still reflects
the current source code.

 o Placement of percent/per-mille.

   Problem: Where can percent/per-mille be placed, and are multiple
   occurrences allowed?

   Solution: The following behaviour was chosen

     a) The percent/per-mille can appear within the prefix, number
        format or suffix.
     b) If it occurs anywhere, the result is multiplied appropriately.
     c) If it occurs within the prefix or suffix, it is displayed
        precisely in the position at which it occurs.
     d) If it occurs within the number format, it is not displayed.
     e) Multiple occurrences are treated as an error.

 o Illegal patterns.

   Problem: How to handle patterns such as "#.#.#".

   Solution: This is treated as an error.

 o Localized zero.

   Problem: If zero is redefined with

     <xsl:decimal-format zero-digit='A'/>

   must the rest of the digits be adjusted accordingly? (e.g. '1' becomes
   'B') JDK 1.1 does not say anything about this. JDK 1.3 says yes.

   Solution: We follow JDK 1.3

 o Default value discrepacy.

   Problem: XSLT and JDK 1.1 disagrees on the following default values.
   Who is right?

      Default value   XSLT        JDK 1.1
     -------------------------------------
      Per-mille       #x2030      ?
      NaN             "NaN"       #xFFFD
      Infinity        "Infinity"  #x221E

   Solution: We use "?", "NaN", and "Infinity" respectively to avoid
   problems with Unicode characters.

 o Strange special characters.

   Problem: What are the "_" and "*" characters mentioned in JDK 1.1, and
   how should they be handled?

   Solution: These characters are not mentioned in JDK 1.3, so we choose
   to regard them as normal characters.

> Just done a bit of background reading into the XSLT2.0 Working Draft, and
> it looks like they've really tightened down the definition.

That is at least encouraging to hear.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]