From 88694e6c1da6d65012aa337ac324ae99514cc76f Mon Sep 17 00:00:00 2001 From: Addison Phillips Date: Fri, 11 Mar 2022 08:49:41 -0800 Subject: [PATCH] Adding best practices for defining identifiers - added charmod-norm requirements not previously imported - added explanations and examples links to each item --- index.html | 52 ++++++++++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 48 insertions(+), 4 deletions(-) diff --git a/index.html b/index.html index c49ceac..7d04acb 100644 --- a/index.html +++ b/index.html @@ -2195,12 +2195,56 @@

Defining elements and attributes

Defining identifiers

-

Identifiers should be case-sensitive.

+

Identifiers should be case-sensitive when non-ASCII characters are allowed and case insensitive when only ASCII characters are allowed.

+ +
+ +
+

Specifications should not allow surrogate code points (U+D800 to U+DFFF) or non-character code points in identifiers.

+ +
+ +
+

Specifications should not allow the C0 (U+0000 to U+001F) and C1 (U+0080 to U+009F) control characters in identifiers.

+
- - - +
+

Specifications that define application internal identifiers (which are never shown to users and are always used for matching or processing within an application or protocol) should limit the content to a printable subset of ASCII. ASCII case-insensitive matching is recommended.

+ +
+ +
+

Application internal identifier fields or values must be wrapped with a localizable display value when displayed to end-users.

+ +
+ +
+

When identifiers are visible or potentially visible to users, specifications should allow the use of non-ASCII Unicode characters, in order to ensure that users in all languages can use the resulting document format or protocol with equal access. Case sensitivity (i.e. no case folding) is recommended.

+ +
+ +
+

If application internal identifiers are not restricted to ASCII, specifications should define the characters that are allowed to start and be part of a valid identifier.

+ +
+ +