Subject: [Lager] [lager] #29 (specification): Referencing the Unicode Character Database

From: "lager issue tracker" <[email-masked]>
Date: Fri, 18 Dec 2015 04:06:53 -0000

#29: Referencing the Unicode Character Database

 UAX 42 ("Unicode Character Database in XML") is referenced in several
 places in the draft.

 In some cases, they should be UAX 44 ("Unicode Character Database").
 Following are where we should change the reference to UAX 44:

 * Section 3.3.7
 * Section 5.2
 * Section 5.2.3

 The UAX 42 reference in Section 4 can stay.

-- 
-------------------------+-------------------------------------------------
 Reporter:               |      Owner:  draft-ietf-lager-
  [email-masked]  |  [email-masked]
     Type:  defect       |     Status:  new
 Priority:  major        |  Milestone:
Component:               |    Version:
  specification          |   Keywords:
 Severity:  -            |
-------------------------+-------------------------------------------------

Ticket URL: <https://trac.tools.ietf.org/wg/lager/trac/ticket/29>
lager <https://tools.ietf.org/lager/>

---

From: "lager issue tracker" <[email-masked]>
Date: Fri, 18 Dec 2015 04:44:08 -0000

Comment (by [email-masked]):

 As this is an XML schema, our intent was to follow "Unicode Character
 Database in XML" [UAX42] in its conventions of referring to properties,
 not merely refer generally to "The Unicode Character Database" in the
 abstract.

 In particular, we considered whether we should allow Unicode's mechanism
 of supporting any mixture of short and long alias, with or without
 optional "_" inserted.

 What decided us against that is that it allows the same property to be
 referred to in multiple ways that cannot be reconciled without access to
 the full description of the Unicode character database. (There's also the
 issue that Unicode can, at any time, define new "aliases" for existing
 properties and values, something that lacks the requisite stability for
 this kind of context).

 Unicode allows, for general use, both a short and a long alias for
 property name as well as property value. (Additional aliases may exist or
 be added over time). Any alias is case insensitive, but also "_" are
 allowed anywhere (as are spaces, when the alias isn't used as an
 identifier, for example, in the text of a specification).

 This would make the following properties identical:
 sc:Common, sc:Zyyy, Script:Commmon, Script:Zyyy
 gc:Mn, gc:Nonspacing_Mark, gc:Non_spacing_Mark, GeneralCategory:Mn,
 Gen_eralCAT_egory:M_n

 and so on. When it comes to designing an XML schema, we felt that this
 freedom of expression has limited benefits but definite costs in
 complexity and risk.

 We noted, that when if came to defining a schema for the representation of
 properties, Unicode itself selects a single representation from among all
 these aliases and thereafter keeps it stable. See [UAX42].

 Therefore, we decided to follow that prescription for the purposes of this
 XML schema.

 In addition to stability, this scheme creates a unique representation for
 each combination of property and property value (and therefore a unique
 representation for any property-derived character class under this
 specification). It also makes LGRs from different sources more readily
 comparable.

 For documentation purposes, in the XML file, the comment field can be
 used, and tools might show both long and short forms to the user, as an
 aid in clarity.

 In response to the reported defect, I would thus suggest going the other
 way, by making the intent (always use the same alias as used in [UAX42]
 more explicit).

  specification          |  Resolution:
 Keywords:               |

Ticket URL: <https://trac.tools.ietf.org/wg/lager/trac/ticket/29#comment:1>
lager <https://tools.ietf.org/lager/>

---

From: "lager issue tracker" <[email-masked]>
Date: Tue, 22 Dec 2015 14:55:08 -0000

Comment (by [email-masked]):

 I agree that having multiple representations increases complexity.

 Also agreed that UAX42 provides a concise listing of the property aliases
 as well as the respective acceptable property values.

 However, UAX42 is not suitable -- at least in some cases -- as a reference
 because it is about the schema of '''UCDXML'''.

 For example, in Section 3.3.7 of the draft, we have:

 > The value of a given Unicode property in [UAX42] may change between
 versions, unless such change has been explicitly disallowed in  [Unicode-
 Stability]

 This is referring to the concept of Unicode properties in general, and
 UAX42 does not seem to be the best fit as a reference. Perhaps simply
 deleting "in [UAX42]" would work, because "[Unicode-Stability]" has the
 relevant pointers to other documents.

 In Section 5.2, we have:

 > by referencing one of the Unicode character properties defined in the
 Unicode Character Database [UAX42];

 Referencing the [http://www.unicode.org/reports/tr44/#Property_Definitions
 UAX44 Property Definitions] is much more appropriate here.

 Even in Section 5.2.3, we should further specify that we support the
 property names and values given in UAX42. Without this qualification,
 UAX42 prescribes its own schema (e.g. most properties are represented as
 XML attributes) which is unrelated to the XML schema that we're specifying
 here.

Ticket URL: <https://trac.tools.ietf.org/wg/lager/trac/ticket/29#comment:2>
lager <https://tools.ietf.org/lager/>