#541 canonical references: imprecise language about software handling and errors


Section #SACR discusses encoding and processing of canonical references. However, there are some suspicious statements:

1) "When an application encounters a canonical reference as the value of cRef attribute, it follows a sequence of specific steps to transform it into a URI reference." -- We seem to be describing how we think hypothetical software operates. I suggest changing "it follows" to "it might follow" or something less cumbersome like "these Guidelines recommend that it follow".

2) "It is an error to reference more matched substrings than are produced by the regular expression." -- Unless one or more of the various schema langauges generated by Roma/Byzantium can detect this, it seems we mean to say that it is not TEI-conformant to encode a document in this way. I suggest changing to say "It is not conformant to these Guidelines to reference [. . .]". Also adjust the wording in the following sentence ("would produce an error").


  • Kevin Hawkins

    Kevin Hawkins - 2013-04-11

    1) Change to "[. . .] of the @cRef attribute, it might follow the following sequence of steps to transform it into URI reference:"

    While we're at it, it would be nice to revise the phrasing around "cRef" in the list below to be cleaner (always say "the @cRef attribute" or "[the value of] the @cRef attribute" as appropriate).

    2) Change to "A cRef pattern should not reference more matched substrings". Also change "would produce an error" to "is faulty."

    Also remove the paragraph beginning "It is quite reasonable".

    Last edit: Kevin Hawkins 2013-04-11
  • Kevin Hawkins

    Kevin Hawkins - 2013-04-11

    Council agreed with subgroup's recommendation in previous comment and assigned to me to implement.

  • Kevin Hawkins

    Kevin Hawkins - 2013-04-11
    • assigned_to: Kevin Hawkins
  • Kevin Hawkins

    Kevin Hawkins - 2013-09-02
    • status: open --> closed-fixed
    • Priority: 5 --> 1(low)