Menu
▾
▴
#421 model.gramPart and <cit>
closed-fixed
5
2012-12-29
2012-07-22
No
Section 9.3.2 (#DITPGR)) explains that gramGrp "can contain any of the morphological elements defined in section 9.3.1 Information on Written and Spoken Forms for form and can appear as a child of entry, form, sense, cit, or any other element containing content about which there is grammatical information." Indeed, <gramGrp> is allowed as a child of <cit>. However, I've just discovered that some though not all of the children of <gramGrp> are allowed as children of <cit>. Specifically, <gen> and <pos> are allowed as children of <cit>, but <gram> is not.
I see two ways to resolve this:
a) <gram> would be allowed as a child of <cit> (that is, all members of model.gramPart would be allowed as children of <cit>). This would make <cit> have a similar content model to <form>. Note, however, that we recently deprecated use of <gram>, <gen>, etc. as children of <form>, instead recommending that they be children of <gramGrp>. See prose in section 9.3.1. (#DITPFO).
b) <gen> and <pos> would be removed from <cit> so that users would need to nest these elements inside <gramGrp> in order to use them inside of <cit>. The <cit> element would then become like <entry> and <sense>.
I recommend (b) since it corresponds to the deprecation decision. However, it also means breaking backwards compatibility. Perhaps a user community survey is warranted?
If the community review doesn't bring shocking news (and I bet that it won't; indeed I share the doubt whether it's needed in this case), I would also support option (b) and gramGrp as the obligatory wrapper.
Recommending b) is the necessary scheme to go to. It allows grammatical description to be coherently combined within an encompassing structure and will improve interoperability across <cit> constructs in dictionaries.
Could it be possible to soft-deprecate gen and pos as member of cit by putting a warning in the documentation and give a 2-year embargo before they are actually disconnected. I am not sure a survey would help in this case.
With option (b), we could indeed deprecate rather than remove elements.
I don't recall the difference between soft deprecation and hard deprecation. It seems that we have only one deprecation practice, which is what Laurent describes. Is that right?
You're right indeed. I was just expressing the feeling that we need to be smooth with the community on this subject. I would indeed be interested to know how many people are using this nice cit+grammatical constraints feature!
Assigning to Kevin. General consensus seems to be that suggestion b) is the right way to go. (And I'd agree with that).
While personally I don't think we'll get much response from a community survey and think this is a corrigible bug, if you guys think doing a survey is worth it, go ahead. The backwards compatibility problem is minor in that an easy XSLT could wrap gen and/or pos when found inside cit inside a gramGrp.
It appears I could carry out (b) by removing gen, number, case, per, tns, mood, and iType from model.entryPart. But the class model.entryPart is also used by dictScrap, entryFree, and nym, but we wouldn't want such a change to affect dictScrap or entryFree. (I think it'd be okay for <nym>.) So I think we'd need to do something more drastic with classes. I need advice on that.
For now, I'll do a deprecation in prose and examples only (akin to what I did at revision 9896 for http://purl.org/tei/bug/3376456 ). I don't see any prose to change, but I've added the wrapper <gramGrp> within <cit> examples at revision 10771.
The obvious way is to use model.gramPart in entryFree and dictScrap. As to nym, we may want to apply the same strategy as for cit (impose using gramGrp). But this should be a specific ticket probably.
Laurent, I don't understand. Right now cit, nym, entryFree, and dictScrap are all members of model.gramPart. As long as all four are members of this model class, any change made for one will affect the others. Can you be more specific about how to "use model.gramPart in entryFree and dictScrap"?
Sorry, I've been too elliptical, I meant that he obvious way is to use model.gramPart in the content models of entryFree and dictScrap, so that you can delete the corresponding direct references in model.entryParts and keep the resulting content models of entryFree and dictScrap unchanged (from the point of view of the elements they may contain).
Helps?
Let me make sure I understand what Laurent is suggesting, and more generally summarize where I think this stands.
Laurent is proposing that in the content models of entryFree and dictScrap, we remove model.entryPart and insert in its place model.gramPart, plus add all other elements currently found in model.entryPart except for gen, number, case, per, tns, mood, and iType. This will result in entryFree and dictScrap having the same content model even though it's expressed differently in the ODD.
Doing this will allow us to remove gen, number, case, per, tns, mood, and iType from model.entryPart in order to carry out option (b) in this ticket. Note that doing so will move us closer to carry out (2) at http://purl.org/tei/bug/3376456 as well.
If we remove elements from model.entryPart, it will affect the content model of nym. One might argue that someone using nym should have a gramGrp wrapper, just as we are deciding for cit and have decided for form ( http://purl.org/tei/bug/3376456 ). An alternative would be to do to nym what we're doing to entryFree and dictScrap. This would leave the content model of nym element unchanged (but expressed differently in the ODD) and let us move forward on removing elements from model.entryPart. Laurent suggests creating a new ticket to decide which way to go with nym.
Does this sound right? If so, I'll create that ticket and postpone this one until that one is resolved.
I just spoke to Laurent, and we have a new plan:
1) Create a new model class (model.structuredEntryPart) which contains as members all of the current members of model.entryPart except for the grammatical features that can occur inside of gramGrp (model.morphLike).
2) Change model.entryPart so that it includes as members model.structuredEntryPart and model.morphLike.
3) Change cit and nym to use model.structuredEntryPart instead of model.entryPart.
We are still not bothering with surveying the community on current use of cit and nym.
[Recategorised as no longer proposing just to change text of Guidelines] Seems reasonable to me.
Note that the new plan from Laurent is to implement (b). Note also that this involves correcting a number of examples in http://www.tei-c.org/release/doc/tei-p5-doc/en/html/DI.html to include the <gramGrp> wrapper.
Decision of Council at FTF 2012-09 in more detail:
1. Create a new model class (model.structuredEntryPart) which contains as
members all of the current members of model.entryPart except for the grammatical
features that can occur inside of gramGrp (model.morphLike).
2. Change model.entryPart so that it includes as members
model.structuredEntryPart and model.morphLike.
3. Change cit and nym to use model.structuredEntryPart instead of
model.entryPart.
This will break backwards compatibility and it would also require changing
examples that will be rendered invalid. We agreed to do these things neverthelesss.
Restating the plan of action more explicitly and correctly (but keeping the numbers here to match things up):
1. Create a new model.structuredEntryPart.xml whose <desc> will be "groups non-morphological elements appearing within a dictionary entry". Change the following elements from being members of model.entryPart to model.structuredEntryPart:
* superEntry
* hom
* sense
* form
* orth
* pron
* hyph
* syll
* gramGrp
* pos
* subc
* colloc
* def
* etym
* usg
* lbl
* xr
* re
2. In the content models of dictScrap and entryFree, replace model.entryPart with both model.structuredEntryPart and model.morphLike. (This will result in an identical content model for each of these elements.)
3. In the content models of cit and nym, replace model.entryPart with model.structuredEntryPart. (This has the effect of preventing use of the morphological elements as children of cit and nym unless a gramGrp wrapper is present. That is, this is where we actually carry out (b) in the ticket.)
4. Update examples in DI in which <cit> or <nym> have morphological elements as children to include the <gramGrp> wrapper now required.
I've just realized that the plan below leaves model.entryPart without being used by any members (since steps 2 and 3 affect all the current members of model.entryPart). So we could delete model.entryPart or, better yet, not even bother creating the new model.structuredEntryPart but instead do the following (again, with step numbers corresponding to the actions in previous comments):
1. Modify model.entryPart so that it's <desc> will be "groups
non-morphological elements appearing within a dictionary entry". Change the following elements so they are no longer members of model.entryPart:
* gen
* number
* case
* per
* tns
* mood
* iType
2. In the content models of dictScrap and entryFree, add model.morphLike. (When done in conjunction with step 1, this will leave these elements having the same content model as before.)
3. Leave the content models of cit and nym unchanged. (When done in conjunction with step 1, this has the effect of preventing use of the morphological elements as children of cit and nym unless a gramGrp wrapper is present. That is, this is where we actually carry out (b) in the ticket.)
4. Update examples in DI in which <cit> or <nym> have morphological
elements as children to include the <gramGrp> wrapper now required.
***
I'm starting to have doubts that I'm correctly reconstructing my plan of action with Laurent, so I'm going to ask him to review this one more time before I implement.
OK. The new proposal is an alternative to the other one with, I think, exactly the same behavior. The advantage I see for the new version is that it places the "notion of structured entry part" et the core of the dictionary chapter since less structured object (dictScrap and entryFree) get additional content. This sound elegant to me and we could imagine in the long run going towards an ideal (LMF compliant ;-)) <entry> and more flexible variants around. So it looks like I like it. But it's Christmas time, I may be too gentle ;-)
The proposal in my comment from 2012-12-28 07:45:23 PST (let's call it "B") is meant to be functionally equivalent to that in my comment from 2012-12-27 19:52:47 PST (let's call this "A"). So, yes, exactly the same behavior. But that means that in both A and B, we are not actually allowing any additional content to dictScrap and entryFree: they will continue to allow the same elements as children as they currently allow, but the system of model classes used to create that set of child elements will change.
Furthermore, B does not introduce "structured entry part" but keeps the old name of "entry part". I realized that A would led us to create a new model class ("structured entry part") but leave the old one ("entry part") without being used by any elements!
Does any of this change your assessment?
With one more night pondering on this I keep having a preference for B. It better expresses the intrinsic structured nature of an entry with entryFree etc. seen as more relaxed constructs. So let's go for B.
Implemented at revision 11281:
http://tei.svn.sourceforge.net/viewvc/tei?view=revision&revision=11281