#289 macro.paraContent out of place in <gram>, etc.

RED
closed-wont-fix
5
2012-06-29
2011-07-24
No

The little grammatical thingies for dictionary description, <gram> and its specializations such as <gen>, <iType>, <per>, <tns>, etc., are defined as containing macro.paraContent -- this is so very clearly wrong.

Discussion

  • Laurent Romary

    Laurent Romary - 2011-07-25

    Can you say why? and by which content would you change this? In marking-up existing dictionary, I would imagine usages where the content is more complex than the systematic codes that modern dictionaries are using.

     
  • Piotr Banski

    Piotr Banski - 2011-07-25

    But, Laurent, do you imagine an <incident>, <catchwords>, <geogName> or <heraldry> as the content of <tns>? You can now practically put anything in there...

     
  • Laurent Romary

    Laurent Romary - 2011-07-25

    Right so. But what would you reduce the content model to?

     
  • Lou Burnard

    Lou Burnard - 2011-07-25

    This is a classic TEI misunderstanding, which really should be in some sort of FAQ somewhere. The fact that some clearly irrelevant children are potentially available is a consequence of (a) the desire to keep the content models as simple as possible (so we don't define different classes for the content of every structurally similar element) (b) the desire to cater for borderline cases. Don't forget that in a real application, you would not include <heraldry> in your schema, so it wouldn't show up in macro.paraContent anyway.

    Very similar concerns were raised about the use of this macro in the content of TEI header elements some time ago, and Council did in that case try to define a different class to contain only elements which might be plausibly used within metadata. You may judge for yourself whether this was a success by looking at the members of model.limitedPhrase, or whatever it was called.

     
  • Piotr Banski

    Piotr Banski - 2011-07-25

    Laurent: I hope that the fact that I don't want to come up with a precise alternative suggestion right now is not meant as a counterargument. But I'll comment on a sketch of a solution below.

    Lou: I understand the puzzle/mosaic idea that you invoke (potential children almost never seriously realised in a schema; my <heraldry> example tastes faintly of bad rhetoric in view of this -- apologies), and the desire to cater for borderline cases, however, such a desire can only go so far, because part of the question is where the borderline can be found. I can't see sensible cases where we could expect phrasal content to be put within <tns> or <per>, which should perhaps ideally be empty elements with maybe @corresp pointing to a definition in the header or the front matter or elsewhere. Possibly allowing rng:text for the sake of a more editorial kind of view. In other words, I question the placement of the borderline that needs to be catered for in this case.

    At this point, someone should invoke *print* dictionaries, and especially historical editions, and some potentially cute stuff one might find in their grammatical descriptions; my answer would be to question the use of the precisely defined elements such as <per>, <number>, etc. for such a purpose. Each of these pieces of information refers to (what should be) a well-defined set of symbolic values -- there is no place for a <quote> or <bibl>, or even a <list> inside them.

    I realise that I am presenting a narrowly focused view, this is intentional. We are possibly (hopefully) coming closer to re-examining the Dictionaries chapter, it would be a good thing for the autumn Council meeting, especially after the Dictionaries workshop at the TEI-MM.

     
  • Martin Holmes

    Martin Holmes - 2011-08-17

    The gist of this argument seems to be that <tns> and friends should be empty elements. However, this bit of the guidelines shows an example in which <tns> has text content, and justifies it:

    http://www.tei-c.org/release/doc/tei-p5-doc/en/html/DI.html#DIMVAV

    1. Would you argue that this inclusion of text content is wrong?

    2. Can you envisage any context in which text content would be appropriate in these elements?

    3. Are there any tags that you think _should_ be allowed in these elements? (That give us some idea of how their content model might be revised.)

     
  • Lou Burnard

    Lou Burnard - 2011-11-02

    The discussion suggests that if this *is* wrong then it is not "clearly" wrong... more discussion is needed, I think.

     
  • Lou Burnard

    Lou Burnard - 2011-11-02
    • milestone: --> RED
     
  • Piotr Banski

    Piotr Banski - 2012-04-17

    Replying to Martin's points:

    1. Would you argue that this inclusion of text content is wrong?

    Nope, it's something we should live with, if all dictionary stuff is kept together, mixing the typographic, editorial and lexical views ( http://www.tei-c.org/release/doc/tei-p5-doc/en/html/DI.html#DIMV )

    2. Can you envisage any context in which text content would be appropriate
    in these elements?

    As above.

    3. Are there any tags that you think _should_ be allowed in these elements?
    (That give us some idea of how their content model might be revised.)

    Ideally none, but on the editorial view, maybe some rendering information (but there's @rend and @rendition, so maybe not even that?)

     
  • Piotr Banski

    Piotr Banski - 2012-06-18

    I am OK with resolving this as WONTFIX -- given that all manner of dictionaries can be marked up with the DI set of tags, I understand the potential difficulties in trying to restrict the content model.

     
  • James Cummings

    James Cummings - 2012-06-29
    • assigned_to: nobody --> louburnard
     
  • James Cummings

    James Cummings - 2012-06-29
    • status: open --> closed-wont-fix
     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks