Re: fixed-length escapes

Hi Michael,

This comment contains the two words "no admissible" after
the last full stop (aka period).  These words look like
detritus from editing.  Should I remove them?

Thanks,
Misha


On 12/07/2002 03:40:00 cmsmcq wrote:
> 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>
>



-------------------------------------------------------------- --
        Visit our Internet site at http://www.reuters.com

Any views expressed in this message are those of  the  individual
sender,  except  where  the sender specifically states them to be
the views of Reuters Ltd.

Received on Friday, 12 July 2002 08:17:35 UTC