deprecate use of gram except as a child of gramGrp

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?

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?

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.

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.

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

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.

Okay, I'm convinced.

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

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.

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.

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.)

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 opened that ticket instead of waiting for Martin to do it: https://sourceforge.net/tracker/?func=detail&aid=3435326&group_id=106328&atid=644062 . ( Once we have these links, users will have an easy way to discover that something has been deprecated.)

Kevin will still implement the deprecation of gram
when not a child of gramGrp.

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.

"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).

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 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.