OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [OASIS Issue Tracker] Updated: (OFFICE-1935) Review 1.2specification with respect to Unicode usage



     [ http://tools.oasis-open.org/issues/browse/OFFICE-1935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Robert Weir  updated OFFICE-1935:
---------------------------------

        Fix Version/s: ODF 1.2 CD 06
                           (was: ODF 1.2)
    Affects Version/s: ODF 1.2 CD 05
                           (was: ODF 1.2)

> Review 1.2 specification with respect to Unicode usage
> ------------------------------------------------------
>
>                 Key: OFFICE-1935
>                 URL: http://tools.oasis-open.org/issues/browse/OFFICE-1935
>             Project: OASIS Open Document Format for Office Applications (OpenDocument) TC
>          Issue Type: Task
>          Components: Locale, Text
>    Affects Versions: ODF 1.2 CD 05
>            Reporter: Robert Weir 
>            Assignee: Robert Weir 
>             Fix For: ODF 1.2 CD 06
>
>
> We should review the ODF 1.2 specification, in particular for the following:
> 1) Are all character literals specifying their code points, e.g., '1' (U+0030).  Remember, not every reader of the standard will be a native English speaker or even a native user of Latin-1 characters.  Since Unicode defines several characters that may look like a plus sign, or a dash, we need to be explicit.
> 2) Are we crystal clear on whitespace treatment?
> 3) Bidi?
> 4) Whenever we talk about sorting, are we clear on whether this is lexical or a locale-dependent collation order?
> 5) What Unicode version? 
> 6) For most of ODF we can deal with Unicode characters and strings of Unicode characters without discussing encodings.  For serialization we permit whatever XML permits and we don't need to deal with encoded characters.  However there are some exceptions that we need to be more explicit with.  One is passwords entered during encryption.  Since the encryption algorithms work at the bit level, both encoding and byte ordering need to be specified.
> 7) Any functions that deal with upper case/lower case conversions, such as in OpenFormula, need to make sure they are specified correctly with respect to Unicode.  
> 8) Anything else?
> Suggest search phrases are: character*, sort, search, collation, unicode, encod*, encrypt*, string (unless it is xsd:string), *space, dash, hyphen, 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]