This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The example "Grouping Nodes based on Common Values" in http://www.w3.org/TR/xslt20/#grouping-examples shows the following result: <table> <tr> <th>Position</th> <th>Country</th> <th>List of Cities</th> <th>Population</th> </tr> <tr> <td>1</td> <td>Italia</td> <td>Milano, Venezia</td> <td>6</td> </tr> <tr> <td>2</td> <td>France</td> <td>Lyon, Paris</td> <td>9</td> </tr> <tr> <td>3</td> <td>Deutschland</td> <td>München</td> <td>4</td> </tr> </table> I think the order in the third cell (List of Cities) in the third row (key France) is wrong, it should be "Paris, Lyon", not "Lyon, Paris", as in the input <city name="Milano" country="Italia" pop="5"/> <city name="Paris" country="France" pop="7"/> <city name="München" country="Deutschland" pop="4"/> <city name="Lyon" country="France" pop="2"/> <city name="Venezia" country="Italia" pop="1"/> city name="Paris" precedes city name="Lyon".
I think one could defend the example on the grounds that the stated requirement is for the output to be "unsorted", i.e. the user does not care what the result order is, and the provided code meets this requirement. However I agree it would be clearer if the published code delivered the published output as shown.
(In reply to comment #1) > I think one could defend the example on the grounds that the stated requirement > is for the output to be "unsorted", i.e. the user does not care what the result > order is, and the provided code meets this requirement. However I agree it > would be clearer if the published code delivered the published output as shown. When I filed this "bug" I had focused on the sample input, output, and XSLT code in the specification. Based on your comment I reread the text accompanying the example again and see that it says "The four columns are to contain [...] third, a comma-separated alphabetical list of the city names within that country". That means the order "Lyon, Paris" is what the textual description specifies, an alphabetical list. Only in that case the XSLT sample does not achieve what the textual description requires, as it outputs "Paris, Lyon". So somehow the textual description, the sample output and the sample XSLT code need to be aligned.
Decided to fix this by adding the required xsl:sort element to the XSLT solution of the example.
This will be erratum E47. I am closing the bug anticipating that this resolution is acceptable.