Template File Syntax (Reference) for Version 7 XML Attribute Files ================================================================== File Layout ----------- All attribute template and instance files must contain the XML element. The following table shows the XML Attributes that can be included in this XML Element. .. list-table:: XML Attributes for Element :widths: 10 40 :header-rows: 1 * - XML Attribute - Description * - Version - Integer value that indicates the SMTK attribute format (Required) Current value is 7 (latest version) * - DisplayHint - Boolean value that indicates if the Attribute Resource should be automatically displayed in an Attribute Editor when loaded into memory. (Optional – default is false which means the Resource will not automatically be displayed) * - TemplateType - A string providing a name for the workflow this attribute describes. (Optional – the default is an empty string.) * - TemplateVersion - An integer describing the version number of the schema for this attribute resource. The default value is 0. This element can contain the following optional children XML Elements: - Includes : used for including additional attribute files (see `Includes Section`_) - AdvanceLevels : used to define various advance access levels used in GUIs (see `Advance Level Section`_) - Categories : used to define workflow specific categories (see `Category Section`_) - Analyses : used to define various analysis groups (see `Analysis Section`_) - Analysis Configurations: predefined analysis configuration from which the user can choose from (see `Analysis Configuration Section`_) - ItemBlocks : used to define reusable blocks of Attribute/Item Definitions Information (see `Item Blocks Section`_) - Templates : used to define reusable parameterized blocks of Attribute/Item Definitions Information(see `Templates Section`_) - Definitions : used to define attribute definitions (see `Definitions Section`_) - Attributes : used to define attributes - Views : used to define various Views (used to create GUIs) Includes Section -------------------- The attribute format supports the ability to include other attribute files. This allows designers to assemble a complete attribute description by referencing attribute files that represent specific aspects. For example a set of attribute definitions may be referenced by several different simulation workflows. Below is an example of including two attribute files both located in a sub-directory IncludeTest. .. code-block:: xml includeTest/b.xml includeTest/a.xml Each include file is contained within a File XML Element. Advance Level Section ------------------------------------- This is an optional section used to describe the various access levels used in GUIs created using SMTK's QT Attribute classes. For example a workflow could consist of the following advance levels: - General - Intermediate - Expert Using the element the following represents the above access levels. .. code-block:: xml 0 1 2 The value of each Level XML Element determines the ordering of the access levels and are used by the items contained within Definitions (see xxx). Notice that in :ref:`the GUI example `, the upper left corner "Show Level" entry is based on the Advance Levels. Advance Level Element Format ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Each advance level is represented by using a XML Element. The value of the element determines the absolute access level and should not be repeated among sibling Level Elements. The higher the value the more "advance" the level. The following table shows the XML Attributes that can be included in this XML Element. .. list-table:: XML Attributes for Element :widths: 10 40 :header-rows: 1 * - XML Attribute - Description * - Label - String value representing the access level name to be displayed in the GUI (Optional - else the label will be the word *Level* followed by the advance level) * - Color - String value representing the color to be used when displaying items that are associated with this access level. The format is "r, g, b" where r, g, and b are a value between 0 and 1 inclusive (Optional) Category Section ---------------- This is an optional section describing the set of categories used within the file. Attribute and Items Definitions can use these categories to define their category constraints. In addition, analyses are defined as sets of categories. For example, the following xml would define the following categories: - Constituent Transport - Heat Transfer - Flow - Time - General .. code-block:: xml Constituent Transport Heat Transfer Flow Time General Each category is contained within a Cat XML Element. The following table shows the XML Attributes that can be included in Element. .. list-table:: XML Attributes for Element :widths: 10 40 :header-rows: 1 * - XML Attribute - Description * - Default - String value representing the default categories a Definition's Item belongs to when no category is specified. Property Section for the Attribute Resource ------------------------------------------- This is an optional section describing a set of properties that should be added to the Attribute Resource. The Property section is defined by a XML **Properties** node which is composed of a set of children **Property** nodes as shown below: .. code-block:: xml 42 3.141 Test string YES You can also look at data/attribute/attribute_collection/propertiesExample.rst and smtk/attribute/testing/cxx/unitXmlReaderProperties.cxx for a sample XML file and test. The following table shows the XML Attributes that can be included in Element. .. list-table:: XML Attributes for Element :widths: 10 40 :header-rows: 1 * - XML Attribute - Description * - Name - String value representing the name of the property to be set. * - Type - String value representing the type of the property to be set. **Note** that the value is case insensitive. The values that the **Type** attribute can be set to are: * int for an integer property * double for a double property * string for a string property * bool for a boolean property The node's value is the value of the property being set. Supported Values for Boolean Properties ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The following are supported values for true: * t * true * yes * 1 The following are supported values for false: * f * false * no * 0 **Note** that boolean values are case insensitive and any surrounding white-space will be ignored. Properties and Include Files ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ If you include an Attribute XML file that also assigns Resource Properties, the include file's Properties are assigned first. Meaning that the file using the include file can override the Properties set by the include file. **Note** - the ability to unset a Property is currently not supported. **Note** - Properties are currently not saved in the XML format, but are saved if using the JSON format. Analysis Section ---------------- This is an optional section that define analyses. An analysis is defined as a resource of categories. For example, using the categories defined in the`Category Section`_, the following XML would define two analyses (Ground Water Flow, and Ground Water with Heat Transfer). .. code-block:: xml Flow General Time Flow General Heat Transfer Time An analysis can be composed of sub-analyses from which the user can choose. By default, the user can select a subset of these sub-analyses as shown below: .. findfigure:: analysisExample1.* :align: center :width: 90% Here you see analysis **B** is composed of 2 optional sub-analyses **B-D** and **B-E**. In this case **B-E** has been selected. An active sub-analysis will add its categories to those of its parent's analysis. The above example could be rewritten using the concept of sub-analyses: .. code-block:: xml Flow General Time Heat Transfer You can also indicate if the user must select only one sub-analysis by indicating that the base analysis is **Exclusive**. In the example below, analysis **C** has been marked **Exclusive** and consists of two sub-analyses **C-D** and **C-E**. The user must select one of these analyses. .. findfigure:: analysisExample2.* :align: center :width: 90% If you wish to have the user exclusively choose among the top level analyses, you can add the Exclusive attribute to the Analyses XML node itself as shown below. .. code-block:: xml A B Please see smtk/data/attribute/attribute_collection/SimpleAnalysisTest.sbt smtk/data/attribute/attribute_collection/analysisConfigurationExample.sbt for complete examples which can be loaded into ModelBuilder. Analysis Element Format ^^^^^^^^^^^^^^^^^^^^^^^ Each Analysis is defined within an XML Tag. The following table shows the XML Attributes that can be included in this XML Element. .. list-table:: XML Attributes for Element :widths: 10 40 :header-rows: 1 * - XML Attribute - Description * - Type - String value representing the type analysis being defined. Note that the type should be unique with respects to all other analyses being defined. (Required) * - BaseType - String value representing the type of the analysis this analysis is a sub-analysis of. (Optional) * - Exclusive - Boolean value indicating the sub-analyses of this analysis are exclusive. (Optional) * - Required - Boolean value indicating the analysis is required and not optional. (Optional) **Note** - Required Analyses can not be sub-analyses of an Analyses with **Exclusive** set to *true*. Each Analysis element contains a set of Cat XML Elements. Analysis Configuration Section ------------------------------ This is an optional section that define analyses configurations. The `Analysis Section`_ describes relationship between analyses, while the configuration section defines various analysis configurations from which the user can choose from. Here is an example configuration section from smtk/data/attribute/attribute_collection/analysisConfigurationExample.sbt: .. code-block:: xml .. list-table:: XML Attributes for Element :widths: 10 40 :header-rows: 1 * - XML Attribute - Description * - AnalysisAttributeType - String value representing the type name for the Attribute Definition used to represent an Analysis Configuration. (Required) The Configuration Element is composed of a set of Config Elements. Each Config Element represents an Analysis Configuration. .. list-table:: XML Attributes for Element :widths: 10 40 :header-rows: 1 * - XML Attribute - Description * - Name - String value representing the configuration's name (which will also be the name of an Analysis Attribute that represents that configuration). (Required) * - AdvanceReadLevel - Integer value representing the configuration's read access level. If the advance level is set below the configuration's AdvanceReadLevel, the configuration will not be displayed to the user. (Optional - default is 0) * - AdvanceWriteLevel - Integer value representing the configuration's write access level. If the advance level is set below the configuration's AdvanceWriteLevel, the user will not be allowed to edit the configuration. (Optional - default is 0) Each Config Element consists of a nested group of Analysis Elements. Each Analysis Element represents an analysis defined in the `Analysis Section`_. Specifying an Analysis indicates that the analysis is active when the configuration is selected. If the analysis is **Exclusive** then it **must** contain an Analysis Element referring to one of its sub-analyses. If it is **not Exclusive** then it can optionally contain multiple Analysis Elements indicating which sub-analyses should be active. .. list-table:: XML Attributes for Element :widths: 10 40 :header-rows: 1 * - XML Attribute - Description * - Type - String value representing an analysis type. Unique Roles Section -------------------- There are use cases where the developer would like to enforce a constraint among ComponentItems such that each item cannot point to the same resource component. In order to provide this functionality, we have introduced the concept of unique roles. Roles in this context refers to the roles defined in the resource links architecture and that are referenced in ReferenceItemDefinition. If the role specified in either a Reference or Component Item Definition is include in this section, it is considered **unique**. Here is an example of an Unique Role Section .. code-block:: xml In this case roles 10 and 0 are considered to be unique. Item Blocks Section --------------------------------- Item Definition Blocks allows the reuse of a group of Attribute / Item Definitions Components in different Attribute/Item Definitions. Providing a "hasA" relationship as opposed to the currently supported "isA". These blocks can then be referenced in the "ItemDefinitions" nodes of Attribute or Group Item Definitions or in the "ChildrenDefinitions" nodes for Reference or Value Item Definitions. Blocks themselves can reference other blocks. But care must be taken not to form a recursive relationship. In the parser detects such a pattern it will report an error. When referencing a Block, the items will be inserted relative to where the Block is being referenced. Category constraints are inherited as usual and that Blocks can call other blocks. Here is an example of an Item Block: .. code-block:: xml Solid Mechanics Fluid Flow Heat Transfer Heat Transfer See data/attribute/attribute_collection/ItemBlockTest.sbt and smtk/attribute/testing/cxx/unitItemBlocks.cxx for examples. The Item Block functionality has been extended so that an Item Block can be exported in one file and consumed in another using the **Export** XML attribute. In order to better organize Item Blocks, we have also introduced the concept of a *namespace* that behaves similar to namespaces in C++. A namespace scopes an Item Block and therefore must also be used when referring to an Item Block. In Version 7 XML files, Item Blocks functionality has been further extended. Blocks can be used within XML Elements: * Definitions * AttDef * Any ValueItemDefinition For example, you can use a Block to contain the discrete information of a String ItemDefinition. **Note** Namespaces are only used w/r Item Blocks (and now Templates) and they can not be nested. .. list-table:: XML Attributes for Element :widths: 10 40 :header-rows: 1 :class: smtk-xml-att-table * - XML Attribute - Description * - Namespace - String value representing the default namespace to which all of its Item Blocks belong to. (Optional) **Note** that if not specified SMTK assumes that the default namespace is the global namespace represented by "" .. list-table:: XML Attributes for Element :widths: 10 40 :header-rows: 1 :class: smtk-xml-att-table * - XML Attribute - Description * - Name - String value representing the name of the ItemBlock. (Required) * - Namespace - String value representing the namespace that the Item Block belongs to. (Optional) **Note** If not specified it will use the default namespace specified in the **ItemBlocks** node. * - Export - Boolean indicating that the ItemBlock should be made available to template files that include this one. (Optional) **Note** If not specified SMTK assumes that the value is *false* meaning that the ItemBlock is file-scope only Templates Section --------------------------------- Templates are a further extension of Item Block's functionality by provided the ability to parameterize the information. A Template Definition is composed of two elements. **Contents** represents the information to be inserted. This is similar to the contents of an ItemBlock. It also can contain an optional **Parameters** element that defines the parameters used in the Template. When referring to a template parameter, you need to enclose it in {}. A declared parameter may be given a default value. When instantiating a Template, you can include a set of Parameters along with their values. **You must include values for all parameters that were not given a default value in the Template's Definition.** A Template can be used anywhere an ItemBlock can be used. When instantiating a Template, the infromation will be inserted relative to where the Template is being referenced. Category constraints are inherited as usual and that Templates can call other Templates. Here is an example of using a Template: .. code-block:: xml