W3C home > Mailing lists > Public > www-i18n-comments@w3.org > April 2004

Arguments vs. return types

From: Björn Höhrmann <bjoern@hoehrmann.de>
Date: Fri, 9 Apr 2004 06:38:53 +0900
Cc: bjoern@hoehrmann.de (Björn Höhrmann)
Message-Id: <889735743.20040408213853@toro.w3.mag.keio.ac.jp>
To: www-i18n-comments@w3.org

This is a last call comment from Björn Höhrmann (bjoern@hoehrmann.de) on
the Character Model for the World Wide Web 1.0
(http://www.w3.org/TR/2002/WD-charmod-20020430/).

Semi-structured version of the comment:

Submitted by: Björn Höhrmann (bjoern@hoehrmann.de)
Submitted on behalf of (maybe empty): 
Comment type: other
Chapter/section the comment applies to: 6.1 String concepts
The comment will be visible to: public
Comment title: Arguments vs. return types
Comment:
Section 6.1, String concepts:

[...]
  C056 [S] Specifications of APIs SHOULD NOT specify single character or
  single encoding-unit arguments. 

  EXAMPLE:  uppercase('ß') cannot return the proper result (the
            two-character string 'SS') if the return type of the
            uppercase function is defined to be a single character.
[...]

The return type of a function is not an argument, hence the example does not match the actual requirement. Also note that "encoding-unit" is not defined in the document; the closest term is probably "units of encoding", if this is the intended meaning, the definition of "units of encoding" should be properly marked up as definition and "encoding-unit" be replaced by "units of encoding".

I do not like this rule, uppercase('ß') is already a good example for an exception, it takes a single character as argument. But you probably want to state this for return types not arguments anyway. I would also prefer to state that this is not recommended over SHOULD NOT (since you might want uppercase transformations that do not change string length, for example).


Structured version of  the comment:

<lc-comment
  visibility="public" status="pending"
  decision="pending" impact="pending" id="LC-">
  <originator email="bjoern@hoehrmann.de"
      >Björn Höhrmann</originator>
  <represents email=""
      >-</represents>
  <charmod-section href='http://www.w3.org/TR/2004/WD-charmod-20040225/#sec-Strings'
    >6.1</charmod-section>
  <title>Arguments vs. return types</title>
  <description>
    <comment>
      <dated-link date="2004-04-08"
         href="http://www.w3.org/mid/889735743.20040408213853@toro.w3.mag.keio.ac.jp"
        >Arguments vs. return types</dated-link>
      <para>Section 6.1, String concepts:

[...]
  C056 [S] Specifications of APIs SHOULD NOT specify single character or
  single encoding-unit arguments. 

  EXAMPLE:  uppercase(&#x27;ß&#x27;) cannot return the proper result (the
            two-character string &#x27;SS&#x27;) if the return type of the
            uppercase function is defined to be a single character.
[...]

The return type of a function is not an argument, hence the example does not match the actual requirement. Also note that &#x22;encoding-unit&#x22; is not defined in the document; the closest term is probably &#x22;units of encoding&#x22;, if this is the intended meaning, the definition of &#x22;units of encoding&#x22; should be properly marked up as definition and &#x22;encoding-unit&#x22; be replaced by &#x22;units of encoding&#x22;.

I do not like this rule, uppercase(&#x27;ß&#x27;) is already a good example for an exception, it takes a single character as argument. But you probably want to state this for return types not arguments anyway. I would also prefer to state that this is not recommended over SHOULD NOT (since you might want uppercase transformations that do not change string length, for example).</para>
    </comment>
  </description>
</lc-comment>
Received on Thursday, 8 April 2004 17:38:57 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 08:32:34 GMT