This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 15646 - Definitions of \i and \c in regular expressions
Summary: Definitions of \i and \c in regular expressions
Status: NEW
Alias: None
Product: XML Schema
Classification: Unclassified
Component: Datatypes: XSD Part 2 (show other bugs)
Version: 1.0 only
Hardware: PC Windows NT
: P2 normal
Target Milestone: ---
Assignee: David Ezell
QA Contact: XML Schema comments list
URL:
Whiteboard:
Keywords:
: 11765 (view as bug list)
Depends on: 11421
Blocks: 11765
  Show dependency treegraph
 
Reported: 2012-01-20 17:40 UTC by C. M. Sperberg-McQueen
Modified: 2012-01-20 17:49 UTC (History)
2 users (show)

See Also:


Attachments

Description C. M. Sperberg-McQueen 2012-01-20 17:40:48 UTC
+++ This bug was initially created as a clone of Bug #11421 +++
+++ Bug 11421 relates to XSD 1.1, this bug to XSD 1.0 +++

The definition of \c is straightforward enough:

   the set of name characters, those matched by NameChar

where NameChar is a link to a production in the XML 1.1 specification.

The definition of \i by contrast is rather strange:

  the set of initial name characters, those matched 
  by NameStartChar in [XML] or by Letter | '_' | ':' 
  in [XML 1.0]

How are we to read this? I don't think "or" here means "the union of
these two sets of characters"; I think it means use one definition if
you're using XML 1.0, a different definition if you are using XML
1.1. But why doesn't it use NameStartChar in both cases? What seems to
have happened is that in XML 1.0 ed 4 and earlier, names were defined
to start with (Letter | '_' | ':'), but in XML 1.0 ed 5, they are
defined to start with NameStartChar (which is a larger set of
characters). So we have chosen a definition that fixes \i to the
pre-5th-edition of XML names, while moving \c forward to the
definition used in 1.0ed5 and 1.1. This can't be right. I would
suggest aligning both character classes with the definitions of XML
names as they appear in XML 1.0 ed 5 and XML 1.1.
Comment 1 C. M. Sperberg-McQueen 2012-01-20 17:48:31 UTC
*** Bug 11765 has been marked as a duplicate of this bug. ***