Thanks for working on this, My advice would be, you will need to add some examples of what an attribute is, Take forexample some-one technical and would love to get acquitted or implementing an attribute in a given class.Forexample
“variable” for x in the example (as shown below). It is actually an attribute of the class. Or you could say that class attributes are variables within a class:
While term “attributes” is used to refer to variables exposed in a Java class and the columns in a database table, I believe TRUNK-2939 is referring to the “attributes” tables in the OpenMRS data model. Using the om.rs/dm data model browser, you can see these tables as an example (that reminds me, now that Ref App 2.10 is released, I need to add it to the browser).
In brief, we have created some tables and corresponding Java classes in OpenMRS where we add “_attribute” to a domain object. The purpose is to allow local extensions to the data model without having to modify the shared (core) data model. It started when @dkayiwa noticed the extensibility of the EAV pattern in our obs table along with several requests from implementations for implementation specific adjustments to the data model (e.g., Tanzania wanted to record the “ten cell” for each person – a convention specific to that region for identifying clusters of homes). He thought, could we apply the extensibility of obs to our person object. So, we created a person_attribute table along with an person_attribute_type table to define custom “attributes” of person that would be an alternative to adding a new column to the person table (since not everyone wants or needs a “ten cell” attribute for person).
This approach of adding an x_attribute table has been repeated for several other domain objects for the same purpose.
So, core OpenMRS knows that attributes exist and can use them (based on their attribute type definition), but core code should never refer to a specific OpenMRS attribute, since any attribute of a table needed by core should instead be added to the core data model directly.
This allows implementations to extend the model where needed and, when we see broad use of the same OpenMRS attributes, we can introduce them directly into the core model. This approach and a desire to align with HL7 FHIR are major drivers behind core data model decisions.
For inter-wiki links (links to other OpenMRS wiki pages), I would recommend using the built in linking (I think you can trigger it by typing an open square bracket [). You did this for one of your references, but not another. Making direct links to other wiki pages (instead of using external links to wiki.openmrs.org/…) allows the wiki to properly track the relationships between wiki pages.