This wiki has undergone a migration to Confluence found Here
Difference between revisions of "VML Processing Widget"
Jump to navigation
Jump to search
Line 45: | Line 45: | ||
**: | **: | ||
* Once the content was posted to the database, the definitive “coremif” was assembled from the Access data by RoseTree, with the “Extensions” merged in by transform. | * Once the content was posted to the database, the definitive “coremif” was assembled from the Access data by RoseTree, with the “Extensions” merged in by transform. | ||
+ | ==Capabilities of the New Widget== | ||
+ | What does this Widget provide? | ||
+ | *A revision of the VML Schema and its placement in the “mif namespace”, that: | ||
+ | *: | ||
+ | *Allows descriptive markup to be validated as the VML files are created | ||
+ | *: | ||
+ | *Extends the VML to include the ability to “update” and “delete” concept properties | ||
+ | *: | ||
+ | *Extends the VML to add the ability to “add”, “update”, and “remove/replace” object properties | ||
+ | *: | ||
+ | *Extends the VML to enable the creation of Value Sets using "extensional definition" against External Code Systems from VML | ||
+ | |||
+ | These extensions are not processed through the extant Java-process. Rather it relies upon pre-defined queries and code (activated from the widget) that perform the necessary data base updates without interfering with the ability to use the original VML for its intended purpose. This is accomplished by: | ||
+ | * Using XSLT transforms to convert and split “revised VML files” into: | ||
+ | **“Standard” VML that can be posted to the data base using the current vocabulary maintenance Java programs, AND | ||
+ | **: | ||
+ | ** Creation a standard data import table (in pipe-delimited format) that defines the data and control codes needed to perform the “extension” queries, | ||
+ | **: | ||
+ | * establishing queries and logic in the Access repository (using Visual Basic fr Applications - VBA - in Access) to post these changes. | ||
+ | *: | ||
+ | * Process controlled by the Java-based ANT scripting language that are controlled from a Work List, and that automate all non-editorial processes |
Revision as of 22:01, 20 June 2014
Summary
One day soon, this page will document the VML Processing Widget. This an ANT-scripted process that:
- consumes proposals for change expressed in the HL7 Vocabulary Maintenance Language (VML),
- splits these proposals into two source streams targeted at the Access repository in which the HL7 Vocabulary content is stored::
- an SQL update stream for updating files of properties assigned to vocabulary objects, and
- an XML stream processed in Java to update the primary Access tables
- together, these streams update the vocabulary content stored in the Access repository,
- an SQL update stream for updating files of properties assigned to vocabulary objects, and
- uses a Java process to "clean up" the Access content,
- invokes RoseTree to express the complete vocabulary content in HL7 Model Interchange Format (MIF), and
- combines this MIF content from the Access repository with an externally maintained MiF extension file to arrive at a final, complete expression of HL7's vocabulary in MIF.
Background - Management of HL7 Vocabulary Content
In brief, the HL7 Vocabulary Content:
- Is published and releases as a formal expression of the content in Model Interchange Format (MIF)files; This format:
- Documents the data that define each of the artifacts (Concept Domains, Code Systems, Value Sets, etc.)
- Documents the relationships between the artifacts (such as bindings);
- Provides a vehicle for using XML X-path logic to query and/or analyze the content;
- Provides the source for transforms used to publish the content in HL7 Ballots and Normative Editions.
- Documents the data that define each of the artifacts (Concept Domains, Code Systems, Value Sets, etc.)
- Is archived and persisted two complimentary forms:
- an Access data base, designed over 13 years ago, that serves as the "repositiry" for this content; plus
- “Extensions files,” represented in MIF format, that primarily document those Value Sets that are defined against external code systems) expressed in MIF
- an Access data base, designed over 13 years ago, that serves as the "repositiry" for this content; plus
- Vocabulary Content is updated through the Vocabulary_and_RIM_Harmonization_Process, the results of which drive updates to the Repository and/or extension files.
Prior to the development of this widget, the means for processing updates to the HL7 Vocabulary Content involved:
- Creating update files expressed in the HL7 Vocabulary Maintenance Language (VML) files.
- "Posting the data in these files to the repository database using the Java-encoded procedures compiled as “VocMaint_and_dependencies.jar”. Weaknesses of this process include:
- Some updates require manual changes (table/row updates) in Access – but only when VML cannot be used. This requirement arose primarily when it was necessary to update concept properties and “object properties” on Concept Domains and Value Sets
- The original VML schema encapsulates “descriptive markup” (html formatting of descriptions), such as the definition of a concept or the description of a value set's content and purpose)in a CDATA wrapper. This encapsulation precluded validation of the markup prior to its being posted to the data base with the too-frequent requirement to cretae a subsequent correction update.
- Some updates require manual changes (table/row updates) in Access – but only when VML cannot be used. This requirement arose primarily when it was necessary to update concept properties and “object properties” on Concept Domains and Value Sets
- Once the content was posted to the database, the definitive “coremif” was assembled from the Access data by RoseTree, with the “Extensions” merged in by transform.
Capabilities of the New Widget
What does this Widget provide?
- A revision of the VML Schema and its placement in the “mif namespace”, that:
- Allows descriptive markup to be validated as the VML files are created
- Extends the VML to include the ability to “update” and “delete” concept properties
- Extends the VML to add the ability to “add”, “update”, and “remove/replace” object properties
- Extends the VML to enable the creation of Value Sets using "extensional definition" against External Code Systems from VML
These extensions are not processed through the extant Java-process. Rather it relies upon pre-defined queries and code (activated from the widget) that perform the necessary data base updates without interfering with the ability to use the original VML for its intended purpose. This is accomplished by:
- Using XSLT transforms to convert and split “revised VML files” into:
- “Standard” VML that can be posted to the data base using the current vocabulary maintenance Java programs, AND
- Creation a standard data import table (in pipe-delimited format) that defines the data and control codes needed to perform the “extension” queries,
- “Standard” VML that can be posted to the data base using the current vocabulary maintenance Java programs, AND
- establishing queries and logic in the Access repository (using Visual Basic fr Applications - VBA - in Access) to post these changes.
- Process controlled by the Java-based ANT scripting language that are controlled from a Work List, and that automate all non-editorial processes