W3C home > Mailing lists > Public > www-i18n-comments@w3.org > July 2002

fixed-length escapes

From: C. M. Sperberg-McQueen <cmsmcq@acm.org>
Date: Fri, 12 Jul 2002 11:40 +0900
To: www-i18n-comments@w3.org
Cc: cmsmcq@acm.org (C. M. Sperberg-McQueen)
Message-Id: <20020712024039.5B12C90D@toro.w3.mag.keio.ac.jp>

This is a last call comment from C. M. Sperberg-McQueen (cmsmcq@acm.org) 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: C. M. Sperberg-McQueen (cmsmcq@acm.org)
Submitted on behalf of (maybe empty): 
Comment type: editorial
Chapter/section the comment applies to: 3.7 Character Escaping
The comment will be visible to: public
Comment title: fixed-length escapes
Comment:
In contemplating the rule "[S] Escape syntax SHOULD either require 
explicit end delimiters or mandate a fixed number of characters in 
each character escape" I am uncertain whether you intend to outlaw the
kinds of escapes defined by section 6.3 of ISO 2022 or not.  ISO 2022
defines some fixed-length and some variable-length escape sequences,
in which certain classes of characters are defined as final 
characters.  These final characters might be viewed as explicit end
delimiters, but they are not solely delimiters.  They are part of the
escape sequence and cannot be disregarded in establishing the meaning
of the escape sequence.

I don't think I have a strong preference for making escape sequences
of this kind legal or illegal here, but I think it probably needs
to be clearer whether they are legal or not.

In the same rule, "Escape syntaxes where the end is determined by a 
character outside the set of characters admissible in the character 
escape itself SHOULD be avoided" is a good provision, but at first
glance it seemed to be saying that the terminating semicolon of 
entity and character references (which is "a character outside the 
set of characters admissible in the character escape itself") was 
being deprecated.  I think rephrasing might help, though I have not
been able to draft a better alternative.
no admissible


Structured version of  the comment:

<lc-comment
  visibility="public" status="pending"
  decision="pending" impact="editorial">
  <originator email="cmsmcq@acm.org" represents="-"
      >C. M. Sperberg-McQueen</originator>
  <charmod-section href='http://www.w3.org/TR/2002/WD-charmod-20020430/#sec-Escaping'
    >3.7</charmod-section>
  <title>fixed-length escapes</title>
  <description>
    <comment>
      <dated-link date="2002-07-12"
        >fixed-length escapes</dated-link>
      <para>In contemplating the rule "[S] Escape syntax SHOULD either require 
explicit end delimiters or mandate a fixed number of characters in 
each character escape" I am uncertain whether you intend to outlaw the
kinds of escapes defined by section 6.3 of ISO 2022 or not.  ISO 2022
defines some fixed-length and some variable-length escape sequences,
in which certain classes of characters are defined as final 
characters.  These final characters might be viewed as explicit end
delimiters, but they are not solely delimiters.  They are part of the
escape sequence and cannot be disregarded in establishing the meaning
of the escape sequence.

I don't think I have a strong preference for making escape sequences
of this kind legal or illegal here, but I think it probably needs
to be clearer whether they are legal or not.

In the same rule, "Escape syntaxes where the end is determined by a 
character outside the set of characters admissible in the character 
escape itself SHOULD be avoided" is a good provision, but at first
glance it seemed to be saying that the terminating semicolon of 
entity and character references (which is "a character outside the 
set of characters admissible in the character escape itself") was 
being deprecated.  I think rephrasing might help, though I have not
been able to draft a better alternative.
no admissible</para>
    </comment>
  </description>
</lc-comment>
Received on Thursday, 11 July 2002 22:40:41 GMT

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