Allow for a constraint: "entry level fields may not interrupt sense level fields"
|Assigned to:||-||% Done:||
When there is a field that I have said is an Entry level field, and it comes in the middle of fields that are Sense level fields, SOLID assumes that it does belong to the Entry, and that the next Sense field starts a new Sense. However, it may simply be that the owner of the database wasn't thinking about fields applying at either the Entry or Sense level--they see no reason not to use the same one all over. And thus they are thinking of it as a Sense-level field, and the next Sense fields are supposed to be part of the same Sense.
I would like something that would warn me when an Entry level field is encountered in the middle of Sense fields. (In many db's I have seen, the Entry level fields are either before or after all the Sense level fields, not in the middle. I would like some sort of option to state that I want that constraint to apply, so SOLID could test for a violation of that constraint.
Hmm, I guess I've made this specific to Entry and Sense. There must be some way to generalize this to other hierarchies that occur as well. For instance, are all example clusters expected to be next to each other, with no other Sense level info between them? That one might not be true. So maybe I really do want it just for the highest level of the hierarchy, and its children that are branching (nodes, not leaves). Or maybe it needs a bit more definition...
Updated by Cambell Prince over 2 years ago
- Target version set to V1.1.x
Maybe we could introduce 'ordering', this field may be at the top / bottom / middle. e.g. bw would typically be bottom, as would dt.
Updated by Beth Bryson over 2 years ago
I'm still eager to see if fixing "allowed once without intervening markers" addresses this. I have a feeling it will.
Updated by J C about 2 years ago
It might be ok to close this one now that http://projects.palaso.org/issues/403 has been resolved. That is, I think that by fixing and improving the "intervening markers" feature, most or all of these issues should go away. If significant ones remain, then exploring the top/bottom/middle idea sounds good to me.
- Status changed from New to Resolved
- Resolution set to fixed
I find that "one or more times together" does the trick nicely, as Beth expected, so I'm closing this.