[CLOSED] Re: [OK?] Re: [SPARQL] i18n comment: Renaming Section on \"Matching Language Tags\"

Hello Eric,

Eric Prud'hommeaux wrote:
> * fsasaki@w3.org <fsasaki@w3.org> [2007-04-19 22:25+0900]
>   
>> Comment from the i18n review of:
>> http://www.w3.org/TR/2007/WD-rdf-sparql-query-20070326/
>>
>> Comment 2
>> At http://www.w3.org/International/reviews/0704-sparql/
>> Editorial/substantive: S
>> Location in reviewed document:
>> Sec. 2.3.1
>> Renaming Section on \"Matching Language Tags\"
>>
>> Comment:
>>  
>> The section title \"Matching Language Tags\" implies matching against language ranges, see comment 3 at
>> http://www.w3.org/International/reviews/0704-sparql/ [http://www.w3.org/International/reviews/0704-sparql/]
>> . However, sec. 2.3.1 does not describe sub tag matching, but only identity of a language tag and given data. Rename proposal: \"Matching the Identity ofLanguage Tags\".
>>     
>
> We use "matches" pretty consistently through the document, though we have a normative ref to 4647 which somewhat coopts the term "matching", especially wrt language tags. Nevertheless, I feel that using a synonym for "matches" on just this section would cost consistency and comprehensibility.
>   

agree.

> I hacked up some modifications to §2.3 (attached) which make the section actually cover 4647.matches. These changes end up referencing SPARQL functions long before they are introduced (§3) so I don't think this is a good idea.
>
> I think a better solution is to rename 3.1-3.3 to
>     * 2.3.1 Matching Literals with Language Tags
>     * 2.3.2 Matching Literals with Numeric Types
>     * 2.3.3 Matching Literals with Arbitrary Datatypes
> which indicates that we are matching RDF terms.
>   

sounds good to me. If you don't here from other i18n core participants, 
please regard the issue as closed.

Felix

> Does this latter solution satisfy you? If so, please respond to this message, prefixing the Subject: with "[CLOSED]". (I forgot to ask you to do that for Comment 1.)
>

Received on Monday, 23 April 2007 01:02:22 UTC