Concept has always stated that the string content should hold the term/code of the controlled vocabulary and therefore it is assumed this usage has been followed by the user. Other elements that have existed and were intended to at some point develop a controlled vocabulary and often contained an attribute abbr or term that would support a single controlled vocabulary term. The parent elements should gain attributes to designate the referenced CV. Most of these are extensions of simpleTextType and do not support the use of markup (<concept><txt>) allowing for multiple language content. These simpleTextType's require duplication to support multiple languages. Of the 40 elements who use base="simpleTextType" I have identified the following which use a type or abbr attribute to "support the future use of a controlled vocabulary". These elements will receive CV identification attributes and expand documentation to indicate how the attribute is to be used. This supports the legacy approach of putting either a term or description into the content of the element by allowing the additional use of a specific term from a controlled vocabulary. For example an respInstru states: "The type of data collection instrument used. "Structured" indicates an instrument in which all respondents are asked the same questions/tests, possibly with pre-coded answers. If a small portion of such a questionnaire includes open-ended questions, provide appropriate comments. "Semi-structured" indicates that the research instrument contains mainly open-ended questions. "Unstructured" indicates that in-depth interviews were conducted. The "type" attribute is included to permit the development of a controlled vocabulary for this element." Following these instructions users would end up creating <resInstru>structured</resInstru>. Using the DDI controlled vocabulary for type of instrument would require changing this content to "Questionairre.Structured". Employing the use of the attribute "term" to contain this term/code allows the addition of the DDI CV term without altering the content. Other legitimate use of this field would be a longer explanation which could be lost if content replacement was required.
COMMONALITIES in base="simpleTextType":
These three objects now have identical contents. Propose changing keyword and topcCla to type="conceptType" this will have no functional difference in the content implementation but will keep these aligned allowing changes to be made only to concept. It also recognizes the commonality of their roles in standard.
COMMONALITIES in base="conceptualTextType" where the original elements provide an attribute designated as a home for a controlled vocabulary (as opposed or in coorignation with interal use of <concept> and <txt> within the structured content.
We are making a change in nation to support the vocab, vocabURI, vocabInstanceURI. For consistency the others should be structured and documented in the same way. Note that timeMeth, dataKind, and resInstru currently have DDI CVs. These are special cases as they already have both internal <concept> option as well as a declared attribute. anlyUnit is something that is a prime candiate for organizational controlled vocablaries
COMMONALITIES in the base="simpleTextType" having attributes designated as CV support. The difference here is that the string content of element is often descriptive in nature. Ideally these would become packaged content of a type with both a description and typeOf... attribute. However, that would break backward compatibility. Three of these have consideration of a DDI CV underway and align with new Lifecycle content. Recommendation would be to add vocab, vocabURI, vocabInstanceURI to the elements to provide support for a CV. These DO NOT follow the description of documentation for concept as that indicates the string of concept should contain the controlled vocabulalry term. These differentiate between the location of the CV content.
The documentation states use to support controlled vocabularies. Doing so requires the addition of the vocab, vocabURI, and vocabInstanceURI.