Filling Out the DD Attribute Class
The <DD_Attribute> class defines a single, specific attribute for use in labels. Attributes defined using this class are grouped into label classes via <DD_Class> definitions. Repeat this class for each specific attribute definition you need to create your local classes.
Last Update: 29 July 2020 for IM 18.104.22.168 (1E00 schemas)
- 1 <name>
- 2 <version_id>
- 3 <local_identifier>
- 4 <nillable_flag>
- 5 <submitter_name>
- 6 <definition>
- 7 <comment>
- 8 <Internal_Reference>
- 9 <Terminological_Entry>
- 10 <DD_Value_Domain>
- 10.1 <enumeration_flag>
- 10.2 <value_data_type>
- 10.3 <formation_rule>
- 10.4 <minimum_characters>
- 10.5 <maximum_characters>
- 10.6 <minimum_value>
- 10.7 <maximum_value>
- 10.8 <pattern>
- 10.9 <unit_of_measure_type>
- 10.10 <specified_unit_id>
- 10.11 <DD_Permissible_Value>
This is the tag name that you'll use in labels to identify this attribute. Tag names are not required to be unique - you can have the same attribute name in different classes with different definitions. This is best used to provide different permissible value lists in different class contexts. In general, it is not a good idea to use the same attribute name to mean completely different things in different classes. Good organization and bookkeeping on this issue will be essential. If you accidentally duplicate a tag name, this may produce subtle errors down the line that could be very hard to diagnose.
There are a couple of major issues with validation, or rather lack thereof, associated with this field:
This is a version specific to this attribute definition. Use it to track progress on specific definitions independently of the dictionary as a whole. This is required to have the format M.n. SBN strongly recommends you increment the major version number when you make a non-backwards compatible change to your attribute definition, and propagate that change to your dictionary <ldd_version_id>.
This identifier must be unique (among <local_identifier> values) within this dictionary, and it is restricted to ASCII. This is the ID you will use to add this attribute to classes. This attribute can, in fact, have exactly the same value as the <name> attribute in the same class, provided that no other <local_identifier> has that value. Some dictionary writers append a prefix related to the containing class or some other circumstance to help with locating attributes and classes for maintenance. This is a particularly good idea when you have attributes with the same name but different definitions (a different permissible value list, for example) in different classes.
The PDS shared namespaces follow this convention: If an attribute is required to appear in a class, but there is a reasonable case in which the attribute might not exist (lost data, or it is not a logically applicable concept in certain contexts, etc.), then the attribute may be nillable. Nillable means that the attribute is still present in the label, but it is explicitly declared to be "nil" and a reason for that is given.
For example, if you defined an attribute call exposure_command that would normally be required in all labels, but might be null because of a known data glitch, then you can declare it null in any particular label by doing this:
<exposure_command xsi:nil="true" nil_reason="missing"/>
or this, which is an alternate but equivalent syntax:
<exposure_command xsi:nil="true" nil_reason="missing"></exposure_command>
In PDS discipline namespaces, an attribute can either be optional or nillable, but is never both in the same context. The list of nil_reason values is in the
pds: namespace Schematron file.
Value values for nillable_flag are true and false.
This is the name of the person responsible for this particular attribute definition. In large projects, dictionary development duties may be delegated to several individuals, and this field enables tracking that responsibility. In small projects, this will be the same as (or equivalent to) the <full_name> value in the <Ingest_LDD> parameters at the top of the file.
This is the human-readable description of the attribute meaning. This will be reviewed by the external reviewers, and will also be available to user for the life of the data set (50 years, at least). As far as reasonable, the definition should not require intimate knowledge of the mission, instrument, or data to understand. So be careful using abbreviations, make cross-references fairly specific, and while you can assume the user looking up this definition is probably looking at a related data label, try not to assume he's read and remembered all the collection documentation.
This is an optional free-text field for additional comments. These are not transferred to the final dictionary files, so they should only be used for comments that are not relevant to end users. You may want to include notes to yourself, for example, or remarks about completion status or team members providing needed information.
Sometimes a picture really is worth a thousand or so words. If you are defining an attribute that, for example, is related to temperature sensors located around the spacecraft, it could be particularly helpful to users if the definition linked to an image file that actually illustrated the physical locations referenced. To do that, label the image as a PDS product and include it in the documentation, then use this class to reference the image from this definition.
Use this method when there is a positive and unique benefit to linking to the cross-referenced product every time the definition is displayed, as in the case above. It would likely be much more distracting than helpful, for example, to link every calibration-related keyword to a calibration document.
This is filled out the same way as in Filling Out the Reference List Classes - <Internal_Reference>, except that the <reference_type> attribute must have the value LDD_to_Source.
The Terminological_Entry class may be used to provide a translation of this definition into a different language. It is intended to be used to support multi-lingual archives. It may not be used to provide alternate and conflicting definitions for the same attribute. Use multiple attributes with the same name and different <DD_Attribute> definitions for creating context-varying definitions for the same attribute name.
Note that you must use a UTF-8 character set for Ingest_LDD files that contain definitions with non-ASCII characters in them. Check your editor settings before you start!
This string contains the translation of the <name> attribute of DD_Attribute into the language specified by <language>. It should be a valid XML ID string (this is not validated); it may contain UTF-8 characters that have the Unicode "alphabetic" property.
This is a free-format text field that contains the translation of the <definition> text of DD_Attribute into the language specified by <language>, following.
The English name of the language used for the name and description translations, above. So far, there are only two standard values defined: English, which may be used only if the primary language of the dictionary is not English; and Russian. If you want to see an additional value added to this list, contact your PDS node consultant and make the request.
If this flag is true, it indicates that this translation of the definition should be preferred over any others that might appear, including the main <definition>. This should never be true for data preparers creating new dictionaries to be archived primarily in the PDS, but as time goes on it may be useful for migrating dictionaries from the archives of the various IPDA partners to archives in other nations, and for international collaborative efforts.
Allowed values are true and false.
Note: This attribute is not well-defined, nor is its use. If you want to include SKOS information in your attribute definition, please contact your PDS node consultant.
This attribute, if it exists, is defined to contain "an identifier for the single occurrence of an object, for instance an XPath". It exists as a handle for applications making use of Terminological_Entry information for advanced or location-specific processing. Routine dictionary operations can carry on happily without it, so you can omit it unless you have a specific use for it in mind - in which case you should be talking with your PDS node consultant.
This extended version of the standard <External_Reference> class includes two additional fields to hold a name and URL. SBN will not allow you to reference a URL in a critical archive document like a mission/project/proposal dictionary, so you should treat this class as if it were a standard <External_Reference>, and fill it out the same way as Filling Out the Reference_List Classes - <External_Reference>, but using the class name External_Reference_Extended. Clarifying <comment> attributes are strongly encouraged.
The DD_Value_Domain class is used to provide constraints on what can appear as a value of the attribute being defined. The more specific you can be here, the more validation can be performed automatically for you in your labels, so SBN recommends you take maximum advantage of the opportunity.
If true, this flag indicates that the attribute has an enumerated value list, which will be defined subsequently. Enumerated value lists are an excellent way to catch and eliminate both human variation and typos in things like names and abbreviations used across instrument teams.
Valid values are true and false.
This field defines the base data type of the attribute. It must be logically consistent with whatever additional constraints you add - so, for example, don't use a numeric data type that can't be less than zero and then try to extend that type by setting <minimum_value> to "-90". This sort of conflict is unlikely to be flagged by validators or LDDTool, and will likely lead to very confusing validation messages for your product labels.
Valid data types are:
The links will take you to descriptions of the various data types.
This is a human-readable description of how valid values for this attribute should be formulated. It might contain, for example, a description of the fields in a spacecraft clock string. It's a good idea to include this description if you are also using <pattern> to constrain the field values, to explain what a non-trivial pattern expression is actually doing.
Use this for any non-numeric attribute values that must have a minimum number of characters. For example, if you are defining a time field that must always be accurate at least to 0.01 seconds, then you can set <minimum_characters> to "11" as a sanity check.
Note that unless your attribute is defined with a data type that preserves all white space, leading and trailing white space is not included in the character count for the value length.
Use this for any non-numeric attribute values that must have a length restriction in the number of characters. For example, if want to make sure that a descriptive field you've defined for your labels will never overflow the 2000 characters you've allocated for it in a mission database, you can set <maximum_characters> to "2000" catch potential overflow cases in validation.
- Unless your attribute is defined with a data type that preserves all white space, leading and trailing white space is not included in the character count for the value length.
- The data types with Short_String in their names are already constrained to be no more than 255 characters long.
Use this to specify a minimum valid value for a numeric field. Typically a field described as a count can never be less that zero, for example, so you can specify that via <minimum_value>.
If your attribute has a defined <unit_of_measure_type>, you should include a <specified_unit_id> (see following) to define what unit of measure the minimum_value is in. You should do this for completeness and to avoid potential future editing errors even if your minimum is zero.
N.B.: Use of <specified_unit_id> is not currently validated. Omitting it can lead to subtle or even undetected validation failures down the road.
Use this to specify a maximum valid value for a numeric field. This is useful, for example, if you're defining a keyword that corresponds to a measurement that is physically constrained. If your instrument can never rotate more than ten degrees off a particular axis, for example, you can specify this via <maximum_value>.
If your attribute has a defined <unit_of_measure_type>, you should include a <specified_unit_id> (see following) to define what unit of measure the maximum_value is in. You should do this for completeness and to avoid potential future editing errors even if your maximum value is zero.
N.B.: Use of <specified_unit_id> is not currently validated. Omitting it can lead to subtle or even undetected validation failures down the road.
Note: LDDTool cannot determine if your pattern will be syntactically valid in the context of the output XML Schema file. Therefore, it is essential that any dictionary preparer who is using the <pattern> attribute check the output XML Schema file for validity before attempting to use it to create or validate labels. You can validate the schema using a validating editor or any other XML schema-based validation tool you might have. (It references the PDS4 core schema, so you will need to feed that into the validator as well.) An invalid pattern in the .xsd file will cause validation failures when attempting to validate a label that will most likely be attributed to a missing or unreadable schema file.
The pattern attribute contains a regular expression pattern (using a syntax defined in the XML Schema standard) that is applied during validation to require that values successfully match the pattern. A <pattern> to require that an ASCII_Integer-type field has exactly ten digits, for example, would look like this:
Regular expressions are as powerful as they are tricky. You should plan to test any patterns in your data dictionary pretty thoroughly for both spurious matches and unintended misses. For a quick summary of the key XML Schema regular expression features, see the XML Schema Regular Expressions - Basics page on this wiki. In addition, PDS imposes the following constraints on this attribute:
- It may not be repeated. The work-around for this is to use a single pattern declaration with each desired pattern parenthesized and separated from the others by the alternation bar (' | ').
- Your pattern may not contain non-ASCII characters, even if you specify them by character entity reference. This effectively prevents detailed pattern validation for any non-ASCII characters, but you can use the standard escape sequences and block escapes recognized by XML Schema (see XML Schema Regular Expressions - Basics).
For background information on units of measure of PDS4 label attributes, see the short page Units of Measure. Consistent with the unit handling in the PDS shared namespaces, when you define an attribute with units in your local dictionary you actually associate the attribute with a class of units via this attribute.
N.B.: If you are defining an attribute that has a natural unit associated with it, you must specify a unit class for it, and you must always specify a unit when you use the attribute in a label. This is a basic and very hard requirement for properly documenting your data. No short-cuts, please.
The valid values for the attribute are the names of the unit classes defined in the
pds: core namespace:
Valid units for each of the types are enumerated on the Unit Classes Standard Values page on this wiki.
N.B.: If you are preparing data for submission to or review by the SBN, do not define an attribute as having Units_of_None. If the value has no units, do not define it with a <unit_of_measure_type>. If a user might expect an attribute with this name to have a unit, state why it does not in the <definition>.
Use this attribute if and only if these two things are both true:
- You have defined a <unit_of_measure_type>.
- You have also defined either a <minimum_value> or <maximum_value>, or both, for this attribute.
If this is the case, you should always include this attribute.
The unit indicated is only applied to the minimum or maximum value in the attribute definition, not to any label value. Specifically, it is not a default unit for the attribute.
It means that, for example, you can define a wavelength range using Ångstroms in your data dictionary, but the labels can use units of nanometers, and the PDS validation tool should be able to deal with the unit difference and make the appropriate check. (But note that I haven't actually checked if this is true.)
This class is used define the enumerated values that are valid for this attribute, with their meanings. You must repeat this class once for each enumerated value you wish to define.
The value string that must be matched exactly in the labels. Both case and imbedded whitespace are significant. Do not include any sort of delimiter around the value you're defining; the <value> and </value> tags are the delimiters.
Enumerated values for things like instrument, phase, or target references can be a particularly effective way to a) make sure everyone is using uniform terminology for key parameters, and b) have the validation software hunt down typos in these critical fields. SBN encourages our data preparers to use enumerated values wherever they can be reasonably applied for these reasons.
This should contain a brief, human-readable definition of the meaning of the related value. So, for example, if your required values are integers representing quality assessments, here's where you say that "O" corresponds to lost data, "1" to questionable data, and so one. If your enumerated values are mission-specific abbreviations, say for operational modes, here's where you can and should spell out the acronyms.
In general, your enumerated values should be reasonably self-explanatory if the attribute meaning is likely to be significant to a typical end-user who is trying to understand a product label. The additional explanation in <value_meaning> should augment the name for users who want a deeper understanding.
As with the main attribute definition, in international collaborations it can be useful to have translations of the standard values and their meanings available in alternate languages. In those cases, the Terminological_Entry provides that capability. It is filled out the same way, and with the same considerations, here as for the DD_Attribute <Terminological_Entry> above.