My vote is form-specific. Basically, we are just trying to leverage/extend the already-existing formFieldNamespace and formFieldPath properties of Obs on other OpenMRS domain objects.
My gut instinct is to prefer “FormField” to “FormRecordable”, but interested in hearing the arguments of one vs the other… thinking about it, I might be changing my mind even as I write this. “HasFormField” and “IsFormField” definitely get thumbs down from me.
Take care, Mark
@mksd does this mean that the implementation already exists in some form? What is the current name?
@ssmusoke this has existed since 1.11.x for Obs only, see the link above. But HFE doesn’t leverage it (yet).
Created:
@mksd then in this case I would go for the longer name FormFieldPathAndNamespace because that is essentially what the interface provides - what they are used for is another matter
Provenance of information is an important consideration, especially in the context of an EHR, but I agree that it’s a somewhat separate concern. At the very least, a generic provenance structure should be able to distinguish between “the patient reported”, “the result of a physical examination”, and “a lab result”.
I only have a small preference on this one, but FormField to me makes it sound as if Obs, Conditions, etc. only exist as form fields. FormRecordable (it’s the -able suffix) sounds more accurate to me, i.e., this can be recorded on a form.
This accurately describes what the interface provides, but I think something like FormRecordable or FormField gets at why these elements are present on the object.
@dkayiwa @ibacher @mogoodrich @ssmusoke, so, the million 
question…
Now that TRUNK-5862 is about to be merged to be part of Core 2.4, would it be also ok to backport it to 2.3.2?
That would make our lives a lot easier.
Ah, right, the tricky backport question. I don’t have a problem with it, but, yeah, although it’s non-breaking it’s definitely a design change, so if anyone has objections they should be strongly considered.
To be noted that we did let it slip with Condition#encounter that was backported to 2.3.x., see here:
Back porting this kind of change is generally against our convention. But whenever the team requesting for a back port is very actively involved in the development of the platform, i vote in favour of the back port. This is mainly because, if we face any unexpected bug from the back port, the same team would be readily available to fix it. In the worst case scenario, we would revert the back port and release a new maintenance version. Of course i also like us to exercise some kind of flexibility such that we do not push implementations to the wall of having no option but fork. 
Great summary @dkayiwa, agreed!
Yes, great summary @dkayiwa. That makes a lot of sense, and thanks for trusting us and being flexible with this.
Follow-up ticket:
<condition/> tag to support a formPath attribute@mogoodrich any preference here?
Bahmni namespaces its form fields with the string "Bahmni", note the capital B that hints at a TitleCase… so should we do
"HtmlFormEntry", or"HFE"?
If anything I think I prefer the former…
I don’t have a strong preference @mksd but think I agree I like the former more… if there’s no space limitations might as well be more explicit.
@mogoodrich, coming back to naming…
See here above how the form tag (or form control)'s namespace and path is decomposed:
{form namespace}^{form name}.{form version}/{control id}-{n}
The part that is explicitly specified when building forms is the control id, should we call it like that then? Any preferences?
<obs conceptId="CIEL:Systolic" formPath="systolic"/>
<obs conceptId="CIEL:Systolic" controlId="systolic"/>
<obs conceptId="CIEL:Systolic" tagId="systolic"/>
IMO formPath creates a confusion with the actual form namespace and path that in the end is the whole thing like: “HtmlFormEntry^Vitals.1.0/systolic-0”.
I think the most general choice, and that would also fit Bahmni Forms’ naming, would be controlId. What do people think? @burke?
I don’t like tagId… if the convention Bahmni started was controlId I guess I’d be okay with it, but I"m not sure why formPath is confusing. This:
form namespace and path = {form namespace}^{form name}.{form version}/{form path}-{n}
… seems clearer than introducing a whole new terminology “control ID”. (Though, of course, the fact that control ID has a precedent in Bahmni gives it value).
Another key point maybe I forgot to mention was I was seeing “formPath” is an actual path in the case of obs groups. As an example:
<obsgroup conceptId="CIEL:Blood Pressure" formPath="blood_pressure">
<obs conceptId="CIEL:Systolic" formPath="systolic"/>
<obs conceptId="CIEL:Diastolic" formPath="diastolic"/>
</obsgroup>
would result in these paths for the three obs:
HtmlFormEntry^Vitals.1.0/blood_pressure-0
HtmlFormEntry^Vitals.1.0/blood_pressure^systolic-0
HtmlFormEntry^Vitals.1.0/blood_pressure^diastolic-0
That seems helpful, though I’m open to the argument that it’s more complicated than needed. This does still seem backwards-compatible with the Bahmni pattern.
Take care, Mark
Ah, actually, just as I write that, I think I see what you are getting at… you are viewing “formPath” in the “filePath” sense? ie it’s the full path to the form, note the path with within the form itself.
Would be interesting to research what the initial design thoughts were. @burke @mseaton any ideas?
controlId seems clear and seems like a good choice to me
If there’s a consensus around controlId, I’m fine with that…