[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: sortAscending?
From:       Patrick Durusau <patrick () durusau ! net>
Date:       2007-10-19 19:10:07
Message-ID: 4719010F.9070901 () durusau ! net
[Download RAW message or body]

Jaroslaw,

Jaroslaw Staniek wrote:
<snip>
>> 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 <table:sort> 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:

<value>ascending</value>
<value>descending</value>

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
[prev in list] [next in list] [prev in thread] [next in thread]