ADA Documentation - Revision history

Kheitmann at 19:49, 9 November 2022

2022-11-09T19:49:20Z

Admin at 21:36, 4 December 2020

2020-12-04T21:36:55Z

Ahenket: /* The ADA XML format */

2020-04-12T15:19:58Z

‎The ADA XML format

Ahenket: /* view */

2020-03-17T18:00:37Z

‎view

Ahenket: /* application */

2020-03-17T17:46:42Z

‎application

Ahenket: /* The ADA XML format */

2019-08-29T07:00:36Z

‎The ADA XML format

Ahenket: /* UI attributes for concepts */

2019-08-29T06:56:22Z

‎UI attributes for concepts

Ahenket: /* view */

2019-08-29T06:53:08Z

‎view

Ahenket: /* ADA Definitions */

2019-07-29T15:04:07Z

‎ADA Definitions

Ahenket: /* view */

2019-07-20T16:52:56Z

‎view

← Older revision		Revision as of 19:49, 9 November 2022
Line 1:		Line 1:
		+	{{SeeNewDocs}}
	This chapter contains the documentation of ART DECOR Applications (ADA), for those who want to start building and deploying ADA apps. ADA apps are fully functional applications, generated from DECOR datasets, transactions and valueSets.		This chapter contains the documentation of ART DECOR Applications (ADA), for those who want to start building and deploying ADA apps. ADA apps are fully functional applications, generated from DECOR datasets, transactions and valueSets.

@@ Line 118: / Line 118: @@
 <syntaxhighlight lang="xml" heading="Application parameters">
      <param name="overrideDatatypeDateTimeAsString" value="true"/>
      <param name="overrideContainsAsIdentifier" value="false"/>
 </syntaxhighlight>
@@ Line 129: / Line 130: @@
 ** T{hh:mm:ss} = today at exactly hh:mm:ss. No need to state seconds
 ** Stating a regular date as YYYY-MM-DD or dateTime as YYYY-MM-DDThh:mm:ss is also possible
 * overrideContainsAsIdentifier - Using this parameter you can override concepts with a contains element, that do not have a valueDomain and are not marked for expansion somewhere to be an item with valueDomain/@type='identifier'. This supports referencing identified 'objects' that live somewhere else although undefined where , like health care provider or patient. The only other way to do this is by listing and overriding each concept separately.

@@ Line 414: / Line 414: @@
 * @root for identifier systems, @value holds the identifier
 * @nullFlavor for unknown @value. Supports any valid NullFlavor, e.g. UNK, MSK, NI. @nullFlavor should not co-exist with coded data. In this case @code will hold the @nullFlavor and @codeSystem points to the NullFlavor code system.
-* @code, @codeSystem, @codeSystemName, @codeSystemVersion, @originalText attribute for coded concepts. @originalText is expected when NullFlavor is OTH.
+* @code, @codeSystem, @codeSystemName, @codeSystemVersion, @preferred, @originalText attribute for coded concepts. @originalText is expected when NullFlavor is OTH.
 * @id supporting a value of type xml:id / xs:ID useful for referring to this concept
 * @datatype supporting any [[DECOR-dataset|DECOR DataSetValueType]]. This is relevant when the dataset concept has the indeterminate value 'complex'. In addition to the DECOR datatypes, there is 'reference' which allows a @value to refer to a concept/@id in the same instance.
@@ Line 422: / Line 422: @@
 * @value + @unit
 * @value + @root
-* @code + @codeSystem, optionally @value and/or @displayName and/or @originalText
+* @code + @codeSystem, optionally @value and/or @displayName, @preferred and/or @originalText
 * @nullFlavor, optionally with @unit or @root, never with @code
 * @datatype (only for complex concepts) with any of the above combinations

@@ Line 112: / Line 112: @@
 * links between views (such as an index which points to detail views)
 * and more, and still more to come.
 ===view===

@@ Line 96: / Line 96: @@
 <applications>
      <application version="1">
          <views>
              <view ...>

@@ Line 274: / Line 274: @@
 |order='1', order='2', order='99'
 |Determines the order in which the concepts are shown in the UI. All concepts siblings must have an order number for this feature to work.
 |}

@@ Line 126: / Line 126: @@
 ** concepts include='all' (All concepts in the DECOR transaction are shown. No concept children are needed, unless you want special processing for those.)
 ** concepts include='only' (No concepts in the DECOR transaction are shown, except the children of <concepts>.)
-* concept/@ref points to a DECOR concept from the DECOR transaction to override properties of and/or add concepts to as first in group or
+** concept/@ref points to a DECOR concept from the DECOR transaction to override properties of and/or add concepts to as first in group or
-* concept/@preceding-ref points to a DECOR concept from the DECOR transaction to add contained concepts before or
+** concept/@preceding-ref points to a DECOR concept from the DECOR transaction to add contained concepts before or
-* concept/@following-ref points to a DECOR concept from the DECOR transaction to add contained concepts after
+** concept/@following-ref points to a DECOR concept from the DECOR transaction to add contained concepts after
-* concept/@widget is used for UI specials (In this example, we'll create two tabs - of course, for a tabbed view, you might want to choose concepts groups on the same depth in the DECOR dataset tree.)
+** concept/@widget is used for UI specials (In this example, we'll create two tabs - of course, for a tabbed view, you might want to choose concepts groups on the same depth in the DECOR dataset tree.)
+** concept/@adaId is used to offer an @id on the concept in the ADA format. This @id is expected to behave like an [https://www.w3.org/TR/xml-id/ xml:id] / [https://www.w3.org/TR/xmlschema11-2/#ID xs:ID]. This concept/@id may subsequently be referred to by a concept[@datatype = 'reference']/@value
 Note that if you are defining extra concepts, than these must be fully populated comparable to concepts in a compiled dataset.

@@ Line 43: / Line 43: @@
 ==ADA Definitions==
 Now make an ADA definition file in /projects/my-project/definitions and call it demoapp-ada.xml. Here's an overview of the structure.
 <syntaxhighlight lang="xml" heading="demoapp-ada.xml Example">
@@ Line 48: / Line 50: @@
 <ada xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:noNamespaceSchemaLocation="../../../core/ada.xsd">
-     <project prefix="demo-" language="en-US"
+     <project prefix="demo1-" language="en-US"
          versionDate="...">
          <release baseUri="http://localhost:8877/decor/services/RetrieveTransaction"/>

@@ Line 117: / Line 117: @@
 * a view/@target (for which we'll explore 'xforms' - html is another obvious candidate)
 * a view/@transactionId and view/@transactionEffectiveDate (this of course identifies the corresponding DECOR transaction)
-* an optional attribute @addComments. If 'true', group headers will have a 'comment' input control where the user can describe the group, particularly useful when ADA is used to make test cases.
+* an optional attribute view/@addComments. If 'true', group headers will have a 'comment' input control where the user can describe the group, particularly useful when ADA is used to make test cases.
-* an optional errorSummary (default 'true') which supresses the Orbeon error-summary. In large forms the error-summary may lead to runtime errors. Set to 'false' to suppress the Orbeon error-summary.
+* an optional attribute view/@errorSummary (default 'true') which supresses the Orbeon error-summary. In large forms the error-summary may lead to runtime errors. Set to 'false' to suppress the Orbeon error-summary.
 * a view/name (which is shown in the browser)
 * one or more view/concepts or (only for indexes) view/indexOf/concepts. concepts come in two flavors:
 ** concepts include='all' (All concepts in the DECOR transaction are shown. No concept children are needed, unless you want special processing for those.)
 ** concepts include='only' (No concepts in the DECOR transaction are shown, except the children of <concepts>.)
-* concept/@ref points to a DECOR concept from the DECOR transaction
+* concept/@ref points to a DECOR concept from the DECOR transaction to override properties of and/or add concepts to as first in group or
 * concept/@widget is used for UI specials (In this example, we'll create two tabs - of course, for a tabbed view, you might want to choose concepts groups on the same depth in the DECOR dataset tree.)
 This view will constitute the main CRUD view to edit or create instances of this particular transaction. The transaction below is a 'measurement form', where a patient can periodically submit weight measurements to a registry (the example is meant to show all main DECOR constructs, and is admittedly somewhat artificial). For CRUD forms, only 'xforms' is currently a valid target environment.