#288 deprecate use of gram except as a child of gramGrp

GREEN
open-accepted
Syd Bauman
5(default)
2013-12-08
2011-07-23
Kevin Hawkins
No

<gramGrp> is allowed as a child of both <form> and <sense>, but <gram> is allowed only as a child of <form>. I would like it added to <sense> as well in keeping with feature request 3266021 and in keeping with section 9.3.2, which implies that you can encode grammatical information either way.

Discussion

1 2 > >> (Page 1 of 2)
  • Piotr Banski
    Piotr Banski
    2011-07-23

    I'd be much happier with the kind of uniformity whereby <gram> is always a child of <gramGrp>. Same about <gram>'s friends. This is of course not going to be optimal for cases where the Dictionaries chapter is meant to describe (some) *print* dictionaries, so maybe this discussion could be extended (its potential target being the next Council meeting) to make the distinction between the various views more fundamental, and e.g. force <gram> and its specializations to always be put into <gramGrp> in the *lexical* view?

     
  • Laurent Romary
    Laurent Romary
    2011-07-24

    I have the same caveat as Piotr on this, namely that I tend to be more and more restrictive on allowed structures for the lexical view. Typically a gram in form sound strange to me since I would recommend to systematically use gramGrp as a container. Just to ask, Kevin, would you have anything against dropping gram from all its possible usages in isolation?

     
  • Kevin Hawkins
    Kevin Hawkins
    2011-07-24

    Piotr suggests a rewriting of the dictionaries chapter to more clearly separate the various "views" of a dictionary, analogous to how we have bibl, biblStruct and even biblFull. I like the idea, but obviously this would be a major project that would break backwards-compatibility on most dictionaries.

    Laurent seems to suggest something more modest: no longer allowing gram to be used except within gramGrp. I'm okay with this.

     
  • Kevin Hawkins
    Kevin Hawkins
    2011-07-24

    Now that I think about it some more, I'm not so sure I like only allowing gram as a child of gramGrp. As a point of comparison, we don't require name to be a child of persName, orgName, etc.; instead, it can be used in place of these elements.

     
  • Piotr Banski
    Piotr Banski
    2011-07-24

    Hi Kevin, I am not sure that the analogy between gramGrp and *Name is valid. gramGrp is not a specialization of <gram>.

     
  • Laurent Romary
    Laurent Romary
    2011-07-25

    Indeed. gramGrp is exactly conceived as a container. Whereas name and persName are at the same level of representation (one more specific than the other). My point is that forcing gram in being in gramGrp would strongly improve interoperability. We could keep the other possibility for a while and indicate its deprecation.

     
  • Kevin Hawkins
    Kevin Hawkins
    2011-07-25

    Okay, I'm convinced.

     
  • Kevin Hawkins
    Kevin Hawkins
    2011-07-25

    • summary: gram in sense --> deprecate use of gram except as a child of gramGrp
     
  • Kevin Hawkins
    Kevin Hawkins
    2011-07-25

    I'm renaming the ticket from "gram in sense" to "deprecate use of gram except as a child of gramGrp"

     
  • Lou Burnard
    Lou Burnard
    2011-11-02

    • milestone: --> AMBER
     
  • Lou Burnard
    Lou Burnard
    2011-11-02

    How is the deprecation to be implemented? just as prose in the guidelines, as schematron rules, or as changes in the content model? More concrete suggestion is needed before we can close this ticket.

     
  • Laurent Romary
    Laurent Romary
    2011-11-03

    The implementation should be made in accordance to the deprecation principles that we established in Chicago:
    - immediate reference in the prose (general, as well as spec of sense and form) that the use of elementary grammatical features outside gramGrp will be deprecated (say in one year)
    - a deprecation ticket is opened accordingly
    - in one year, the corresponding content models are changed.

     
  • Lou Burnard
    Lou Burnard
    2011-11-09

    • assigned_to: nobody --> kshawkin
    • status: open --> pending
     
  • Kevin Hawkins
    Kevin Hawkins
    2011-11-09

    No Schematron rule is to be implemented. A "deprecation ticket" is a ticket in SourceForge in the category "deprecated" in SF. (We will need to add a link to a list of all deprecated tickets to the TEI website.)

     
  • Kevin Hawkins
    Kevin Hawkins
    2011-11-09

    • assigned_to: kshawkin --> nobody
    • status: pending --> open
     
  • Kevin Hawkins
    Kevin Hawkins
    2011-11-09

    Make deprecation ticket a feature request, not a bug.

    There will be two links: one for open deprecation tickets and one for closed tickets. Martin will open a ticket to create these links.

     
  • Lou Burnard
    Lou Burnard
    2011-11-09

    • assigned_to: nobody --> kshawkin
     
  • Kevin Hawkins
    Kevin Hawkins
    2011-11-09

    • status: open --> pending
     
  • Kevin Hawkins
    Kevin Hawkins
    2011-11-13

    • status: pending --> open
     
  • Kevin Hawkins
    Kevin Hawkins
    2011-11-30

    While implementing this, I realized it doesn't make sense to deprecate only use of gram outside of gramGrp: the following should also be similarly deprecated outside of gramGrp: gen, number, case, per, tns, mood, iType, pos, subc, and colloc. Doing so will not interfere with use of entryFree or the Editorial View of dictionaries because gramGrp allows for text content. However, there may be cases where an entry has grammatical information that is interrupted by non-grammatical information, thereby requiring more than one gramGrp.

    However, I now see that section 9.3.2 says:

    Elements conveying morphological information bear different interpretations within gramGrp and form groups, the difference being that in the form group, the morphological information specified pertains to the specific alternate form in question, while within gramGrp it applies to the headword form.

    If we stick to this principle, we in fact shouldn't eliminate gram or any of the other elements as children of form. Or we should reword this to say the following:

    Elements conveying morphological information bear different interpretations depending on whether they are descendents of the form element. In the form group, the morphological information specified pertains to the specific alternate form in question, while outside form it applies to the headword form.

    In short, there are too many uncertainties to implement without further discussion.

     
  • Laurent Romary
    Laurent Romary
    2011-12-01

    "within gramGrp it applies to the headword form": this is definitely nonsense and exactly the kind of things which should be revised in relation to this ticket. We should make it clear that the recommended practice (if not more) is to use gramGrp at any place where there is a need for specifying grammatical constraints (at entry level, for a specific form, or within a sense to express local morpho-syntactic constraints associated to the specific meaning).

     
  • Kevin Hawkins
    Kevin Hawkins
    2011-12-02

    I have always interpreted the sentence:

    Elements conveying morphological information bear different interpretations within gramGrp and form groups, the difference being that in the form group, the morphological information specified pertains to the specific alternate form in question, while within gramGrp it applies to the headword form.

    this way:

    Elements conveying morphological information bear different interpretations
    depending on whether they are descendents of the <form> element. Within the <form> element, any morphological information specified pertains to the specific
    alternate form in question, while outside <form> it applies to the headword
    form.

    If this is what the Guidelines actually intend, then this would clarify existing practice without changing anything. But I'm not even sure that's what's intended, and I don't feel comfortable making this decision unilaterally.

    Alternatively, in line with the ticket, we could go one step further to instead say:

    Elements conveying morphological information bear different interpretations
    depending on whether they are descendents of the form element. Within the <form> element, any morphological information specified in <gramGrp> pertains to the specific alternate form in question, while a <gramGrp> outside <form> applies to the headword form.

    But before doing this, I would want to know whether to deprecate use of the other elements I listed in addition to <gram>.

     
  • Kevin Hawkins
    Kevin Hawkins
    2011-12-05

    Kevin and Laurent just discussed by Skype and agreed that Kevin will do the following:

    1) Change the prose of DI to deprecate use of not only gram but also gen, number, pers, etc. outside of gramGrp. (Laurent believes that the discussion in Paris about only gram was meant as shorthand for all of these elements.)

    2) Create a deprecation ticket about (1) so that this change can be made in the content models in the future.

    3) Remove the meaningless sentence "Elements conveying morphological information bear different interpretations within gramGrp and form groups, the difference being that in the form group, the morphological information specified pertains to the specific alternate form in question, while within gramGrp it applies to the headword form." (Kevin's interpretation doesn't really make sense either since even a headword is in a <form>!)

    4) Add a note to the definition of gramGrp that this element could be a child of entry, form, sense, cit, or any other element containing content about which you want to give grammatical information.

     
  • Kevin Hawkins
    Kevin Hawkins
    2011-12-05

    • status: open --> pending
     
1 2 > >> (Page 1 of 2)