#224 <idno> content model


The <idno> content model is currently text only. This is plainly ridiculous because an identification number can contain all sorts of characters. Especially because the locations <idno> is available has been decided to be increased recently. This might include characters that are not yet in Unicode, especially if <idno> is being used to record complete fantastical or mythological identification numbers. If changing this content model to include model.gLike it would also potentially make sense to add model.glossLike in order to give <idno> a <desc> child to document the nature of this <idno>.


  • Syd Bauman

    Syd Bauman - 2010-04-30

    While I am not convinced this idea is crazy, it does seem like sliding down a slippery slope. <idno> is about (modern) metadata, no? Isn't part of the point (if not the whole point) of having <idno> over and above <num type="used-for-identification"> just so that its syntax and semantics are more predictable?

    I would really like to be able to tell processors they can harvest routine metadata from TEI documents without having to figure out what to do with <g> elements. Or <desc> children, for that matter.

    And I would really be happy to help discourage designers of metadata systems from using characters outside of Unicode. In fact, I'm going to take issue with the thesis statement of the original request: “an identification number can contain all sorts of characters”. If it contains characters that no audience could possibly process, in what way is it useful as an identification? Remember, <idno> is not descriptive in the sense of “describing what function this string served in the source”, but rather is proscriptive in the sense of telling users of TEI documents “this is an identification of said bibliographic item” or some such.

  • Lou Burnard

    Lou Burnard - 2010-05-06

    I tend to agree with Syd here. if the identification is fantastical or mythological wouldn't that make it a name rather than an idno? I suppose there's a case for changing the model to macro.xText, but no more than that.

  • Martin Holmes

    Martin Holmes - 2010-08-13

    I agree with Syd and Lou in wishing to discourage the use of non-Unicode characters for something like an <idno>, although I am tempted by the idea of making <desc> available in <idno>.

  • Lou Burnard

    Lou Burnard - 2010-09-13

    Proposal is to change content model to macro.xText to permit non-Unicode glyphs in an identifier; in the rare case where there's a need to describe or gloss the identifier this will have to be done by a sibling element. If a real example of this need is forthcoming we could add it to the text.

  • Martin Holmes

    Martin Holmes - 2010-09-13

    On reflection, I agree with Syd: idno's value comes from its simple parsability. There are lots of other tags which can be used to encode exotic identifiers where this is required.

  • Nobody/Anonymous

    I too agree with Syd. Keep it real, keep it useable. This is modern metadata, not descriptive of a printed text or the ilk

  • Kevin Hawkins

    Kevin Hawkins - 2010-09-13

    idno is used by members of model.nameLike. As such, it can be used in the body of the a document, not just in modern metadata in the fileDesc. So if I'm encoding a typewriter manuscript of a list of names of spies with their ID numbers but some of these numbers have been corrected with pen, I should be able to use <corr> etc. within <idno>. Therefore, I think macro.xText is insufficient.

  • Laurent Romary

    Laurent Romary - 2010-09-14

    Kevin's argument is quite convincing. I would suggest:
    - to extent the content model of idno as he suggests
    - to clearly document what was referred to as "modern" metadata in the discussion (discouraging the use of non unicode characters)

  • Nobody/Anonymous

    I'm happy with macro.xtext because my prime concern in suggesting this was that it is completely western-centric to believe that you won't need <g> inside an id number. There are characters in use today which haven't (yet hopefully) made it into Unicode. I can't off hand think of a place in the TEI where the freetext-content of an element should not also allow the <g> character. That is the reason we created <g> and also underwent that class warfare to remove freetext-bearing attributes.

    Having it allow model.glossLike as content was a bonus suggestion...Kevin's argument is interesting but to me either that is a gloss list or a table, or contains some <num>007</num> elements or similar.

    Partly this is a problem of context: In the header I want it just to be alphanumeric for simplicity, but because it is included in model.nameLike it is available all sorts of places in a transcription and in *that* context I want it to have <g> (and potentially <desc>).

    I'm happy with macro.xtext, if anyone complains later that they need it expanded, perhaps re-examine it at that point. My use-cases are all hypothetical, I was really only pointing out an inconsistency.

  • James Cummings

    James Cummings - 2010-09-14

    Erm, that last comment was me (JC)... I thought we'd turned off anonymous commenting?

  • Lou Burnard

    Lou Burnard - 2010-11-01
    • assigned_to: nobody --> louburnard
    • status: open --> open-remind
  • Lou Burnard

    Lou Burnard - 2010-11-01

    No-one disagrees that macro.xtext would be an improvement on the present situation, so I have applied that change pending further discussion.

  • Lou Burnard

    Lou Burnard - 2011-03-20

    Closed since there has been no further discussion and the solution seems to meet most of the original requestor's concerns,

  • Lou Burnard

    Lou Burnard - 2011-03-20
    • status: open-remind --> closed-remind