From koffice-devel Fri Oct 19 19:10:07 2007 From: Patrick Durusau Date: Fri, 19 Oct 2007 19:10:07 +0000 To: koffice-devel Subject: Re: sortAscending? Message-Id: <4719010F.9070901 () durusau ! net> X-MARC-Message: https://marc.info/?l=koffice-devel&m=119282218400734 Jaroslaw, Jaroslaw Staniek wrote: >> I will be raising this issue in the ODF TC but I am hopeful that the >> developers on this list may have some suggestions in terms of what >> should be considered in terms of standardizing some basic set of sort >> orders. >> >> Defining even basic sort orders by reference to established standards >> would be much preferred over cooking our own definitions. > > Hello and welcome Patrick, > > There is defined in ODF (I can see it after quick check). > What exactly more and in which context do we need? > Yes, but when you run the table:order attribute to ground you will find: table-sort-by-attlist, which has the following enumerated values: ascending descending 1. That is only for tables and not the other occurrences of ascending/descending, and 2. We never define ascending/descending. I realize that for ASCII, we assume A-Z/a-z is ascending and Z-A/z-a is descending, but since this is an Unicode based standard, it seems a bit odd to simply presume that and to not explicitly say what we mean by ascending/descending. At a minimum, I think we should say one of the following: 1. Ascending/descending is language dependent. Sort of a coward's way out but it doesn't leave ascending/descending just hanging in the air. 2. Ascending/descending is language dependent *and* here are the standard definitions of those orders for some set X of languages. With a user defined option for those we don't cover. 3. (For completeness sake) We define ascending and descending to be A-Z/a-z and Z-A/z-a, respectively and any other sort order is simply up to the application and not stored in the file for being passed to the next application that opens the file. (Obviously not my choice but including it perhaps makes the issue clearer.) My concern is with what the standard states what is the expected behavior and that I have some reasonable expectation that when I go from one application to another that the file contains sufficient information that I can get the same behavior from different applications. Compare the section on Embedded Number Behavior (which I don't hold forth as a model of clarity) but we do attempt to define the expected behavior from any application that supports that feature. I am not contending for any particular behavior or another but simply that we sufficiently define the behaviors that are expected. I would suggest that we define ascending/descending in all contexts in which it appears. This does not mean that all applications must support, for example, a defined sort order on Chinese, but it does mean that the ODF file would contain the information necessary for an application that does support that sort order to know which one to use. To a degree this is a standards writer's concern because anything we don't define is just that, not defined. Any behavior is acceptable under the terms of the standard if it is not defined. That seems to me to impair reliable interchange of documents. Does that help/confuse? Apologies for the length. I am uncertain about the customs of this list with regard to postings. I think of it as being thorough, my wife says the term is long-winded, so opinions vary. ;-) Hope you are looking forward to a great weekend! Patrick -- Patrick Durusau patrick@durusau.net Chair, V1 - US TAG to JTC 1/SC 34 Acting Convener, JTC 1/SC 34/WG 3 (Topic Maps) Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps) Co-Editor, OpenDocument Format (OASIS, ISO/IEC 26300) _______________________________________________ koffice-devel mailing list koffice-devel@kde.org https://mail.kde.org/mailman/listinfo/koffice-devel