Aggregated RFC-2119 statements
This appendix contains all the normative
statements from the DITA 2.0 specification. They are aggregated here
for convenience in this non-normative appendix.
Aggregated error statements
- DITAERR-0010
- Processors MAY choose to treat this as an error, issue a warning, or simply assign new roles to the problematic elements.
- DITAERR-0020
- If the value of the
@hrefattribute is not a valid URI reference, an implementation MAY generate an error message. - DITAERR-0030
- It MAY also recover from this error condition by attempting to convert the value to a valid URI reference.
- DITAERR-0040
- Applications MAY recover from this error condition by using the correct value detected.
- DITAERR-0050
- If it is an error for the element to be empty, an implementation MAY give an error message; it also MAY recover from this error condition by leaving the key reference element empty.
- DITAERR-0060
- Therefore, it is an error if the following conditions occur:
- DITAERR-0070
- A processor MAY give an
error message when it encounters the following error conditions:
- An
<indexterm>element contains an<index-see>element, and the publication contains one or more<indexterm>elements with matching textual content. - Both
<index-see>and<index-see-also>elements within the same<indexterm>element.
<index-see>element as an<index-see-also>element. - An
- DITAERR-0080
- Processors might choose to handle this error condition different.
- DITAERR-0090
- It is an error for two source topics to replace the same element.
- DITAERR-0100
- The conref push function does not provide the ability to push
a range of elements, so it is an error to specify the
@conrefendattribute together with the@conactionattribute. - DITAERR-0110
- When encountering an error condition, an implementation can issue an error message.
- DITAERR-0120
- It is an error if
<ditavalref>-driven branch cloning results in multiple copies of a topic that have the same resolved name. - DITAERR-0130
- Processors SHOULD report an error in such cases.
- DITAERR-0140
- A processor MAY consider this form of equivalence when determining if two references to the same resource should be reported as an error.
- DITAERR-0150
- This saves considerable time and effort, reduces error, enforces consistency, and makes interoperability possible.
- DITAERR-0160
- It is an error if the root element matches a specified
source but its
@classattribute does not contain the target. - DITAERR-0170
- It is an error if the last value in the
@classattribute matches a specified source but the previous values do not include the target. - DITAERR-0180
- This is an error condition, since it means the document has been only partially generalized, or that the document has been generalized and then edited using a specialized document type.
- DITAERR-0190
- Processors SHOULD treat the presence of more than one
<title>element in a<example>element as an error. - DITAERR-0200
- Processors SHOULD treat the presence of more than one
<title>element in a<section>element as an error. - DITAERR-0210
- The spec says that if your scheme tells you "a" and "b" are the only valid values in an attribute, then specifying "x" and "y" are both in error, and processors / applications can treat that as an error.
- DITAERR-0220
- If you set up that scheme but your grammar files only allow "x" and "y", then you've set up a scheme that means every usage of that element is automatically an error condition.
- DITAERR-0230
- For
situations where resource names are relevant, it is an error condition for multiple
<ditavalref>elements to result in conflicting resource names for different content. - DITAERR-0240
- It is an error if the value of this attribute is not an unsigned integer.
- DITAERR-0250
- In this case, the implementation might give an error message and might recover by ignoring this attribute.
- DITAERR-0260
- When a map that contains a
<topicgroup>element with a navigation title is used to generate publication output, processors MUST ignore the navigation title and MAY issue an error message. - DITAERR-0270
- It is an error if there is more
than one
<sort-as>child for a given<indexterm>element. - DITAERR-0280
- The following markup in a DITAVAL document is an error condition:
- More than one
<prop>element with no@attattribute - More than one
<prop>element with the same@attattribute and no value - More than one
<prop>element with the same@attattribute and same@value
- More than one
- DITAERR-0290
- It is an error to include more than one
<revprop>element with the same@valattribute. - DITAERR-0300
- Recovery from this error is implementation dependent.
- DITAERR-0310
- In such cases processors MAY provide an error or warning message.
- DITAERR-0320
- It is an error to use
parse="xml"anywhere other than within<foreign>or a specialization thereof. - DITAERR-0330
- It is an error to use
parse="xml"anywhere other than within<foreign>or a specialization thereof. - DITAERR-0340
- If content referencing is resolved after filtering, the referenced element is filtered out and the content reference cannot be resolved, typically generating an error.
- DITAERR-0350
- The difference in these two cases is that in the first case the content reference cannot be resolved, resulting in a processing error and a potentially nonsensical element if the referencing element has required subelements (for example, a content reference from a topic to another topic, where the referencing topic must have a title subelement), but in the second case the element is filtered completely out.
Aggregated RFC-2119 statements
- DITAREQ-0010
- A DITA document MUST have as its root
element one of the following elements:
<map>or a specialization of the<map>element<topic>or a specialization of the<topic>element<dita>, which cannot be specialized, but which allows documents with multiple sibling topics
- DITAREQ-0020
- Files that contain DITA content SHOULD use the following
file extensions:
- DITA topics
- *.dita (preferred)
- DITA maps
- *.ditamap
- Conditional processing profiles
- *.ditaval
- DITAREQ-0030
- If the root element of a map or a top-level topic has no value for the
@xml:langattribute, a processor SHOULD assume a default value. - DITAREQ-0040
- When a
@conrefor@conkeyrefattribute is used to include content from one element into another, the processor MUST use the effective value of the@xml:langattribute from the referenced element. - DITAREQ-0050
- Processors SHOULD render each
element in a way that is appropriate for its language as identified
by the
@xml:langattribute. - DITAREQ-0060
- DITA processors SHOULD fully support the Unicode Bidirectional Algorithm.
- DITAREQ-0070
- Processors MAY choose to treat this as an error, issue a warning, or simply assign new roles to the problematic elements.
- DITAREQ-0080
- Processors also MAY provide parameters by which subject scheme maps are referenced.
- DITAREQ-0090
- Authoring tools SHOULD use these lists of controlled values to provide lists from which authors can select values when they specify attribute values.
- DITAREQ-0100
- Authoring tools MAY give an organization a list of readable labels, a hierarchy of values to simplify selection, and a shared definition of the value.
- DITAREQ-0110
- Authoring tools MAY support accessing and displaying the content of the subject definition resource in order to provide users with a detailed explanation of the subject.
- DITAREQ-0120
- If an enumeration is bound, processors SHOULD validate attribute values against the controlled values that are defined in the subject scheme map.
- DITAREQ-0130
- Processors SHOULD be aware of the hierarchies of attribute values that are defined in subject scheme maps for purposes of filtering, flagging, or other metadata-based categorization.
- DITAREQ-0140
- Processors SHOULD validate that the values of attributes that are bound to controlled values contain only valid values from those sets.
- DITAREQ-0150
- Processors SHOULD check that all values listed for an attribute in a DITAVAL file are bound to the attribute by the subject scheme before filtering or flagging.
- DITAREQ-0160
- If a processor encounters values that are not included in the subject scheme, it SHOULD issue a warning.
- DITAREQ-0170
- Processors SHOULD apply the following algorithm when they
apply filtering and flagging rules to attribute values that are defined as a hierarchy of
controlled values and bound to an enumeration:
- If an attribute specifies a value in the taxonomy, and a DITAVAL or other categorization tool is configured with that value, the rule matches.
- Otherwise, if the parent value in the taxonomy has a rule, that matches.
- Otherwise, continue up the chain in the taxonomy until a matching rule is found.
- DITAREQ-0180
- When determining the value of an attribute, processors MUST evaluate each attribute on each individual element in a specific order. This order is specified in the following list.
- DITAREQ-0190
- Applications MUST continue through the list until a value is established or until the end of the list is reached, at which point no value is established for the attribute.
- DITAREQ-0200
- For attributes within a map, the following processing order MUST occur:
- The
@conrefand@keyrefattributes are evaluated. - The explicit values specified in the document instance are
evaluated. For example, a
<topicref>element with the@tocattribute set to "no" will use that value. - The default or fixed attribute values are evaluated. For example, the
@tocattribute on the<reltable>element has a default value of "no". - The default values that are supplied by a controlled values file are evaluated.
- The attributes cascade.
- The processing-supplied default values are applied.
- After the attributes are resolved within the map, any values that do not come
from processing-supplied defaults will cascade to referenced maps.
For example, most processors will supply a default value of
toc="yes"when no@tocattribute is specified. However, a processor-supplied default oftoc="yes"does not override a value oftoc="no"that is set on a referenced map. If thetoc="yes"value is explicitly specified, is given as a default through a DTD, RNG, or controlled values file, or cascades from a containing element in the map, it will override atoc="no"setting on the referenced map. See ../map-to-map-cascading-of-metadata.html for more details. - Repeat steps ../dita-2.0-specification.aggregated.html#processing-cascading-attributes-in-a-map__common-start to ../dita-2.0-specification.aggregated.html#processing-cascading-attributes-in-a-map__common-end for each referenced map.
- The attributes cascade within each referenced map.
- The processing-supplied default values are applied within each referenced map.
- Repeat the process for maps referenced within the referenced maps.
- The
- DITAREQ-0210
- If no value is set for the
@mergeattribute and no value cascades from a containing element, processors SHOULD assume a default of merge. - DITAREQ-0220
- Implementers MAY define their
own custom, implementation-specific tokens for the
@mergeattribute. - DITAREQ-0230
- To avoid name conflicts between implementations or with future additions to the standard, implementation-specific tokens SHOULD consist of a prefix that gives the name or an abbreviation for the implementation followed by a colon followed by the token or method name.
- DITAREQ-0240
- The predefined values for the
@cascadeattribute MUST precede any implementation-specific tokens, for example,cascade="merge appToken:audience". - DITAREQ-0250
- When the source document organization has no effect on published output, such as
when producing a single PDF or EPUB, processors MAY ignore the
@chunkattribute. - DITAREQ-0260
- When the
@chunkattribute results in more or fewer documents based on thecombineorsplittokens, the hierarchy of topics within the resulting map and topic organization SHOULD match the hierarchy in the original topics and maps. - DITAREQ-0270
- When the
@chunkattribute results in more or fewer documents, processors MAY create their own naming schemes for those reorganized documents. - DITAREQ-0280
- Processors MAY apply equivalent processing to non-DITA documents.
- DITAREQ-0290
- Within a map document, the values of the
@idattributes for all elements SHOULD be unique. - DITAREQ-0300
- When two elements
within a map have the same value for the
@idattribute, processors MUST resolve references to that ID to the first element with the given ID value in document order. - DITAREQ-0310
- If the actual format of the referenced content differs from the
effective value of the
@formatattribute, and a processor is capable of identifying such cases, it MAY recover gracefully and treat the content as its actual format. - DITAREQ-0320
- The processor MAY also issue a message.
- DITAREQ-0330
- The value of the
@hrefattribute MUST be a valid URI reference [RFC 3986]. - DITAREQ-0340
- If the value of the
@hrefattribute is not a valid URI reference, an implementation MAY generate an error message. - DITAREQ-0350
- It MAY also recover from this error condition by attempting to convert the value to a valid URI reference.
- DITAREQ-0360
- Processors MUST always consider relative URIs as local by default.
- DITAREQ-0370
- Applications MAY issue a warning
when the specified or inherited
@typeattribute value does not match the target or a specialization ancestor of the target. - DITAREQ-0380
- Applications MAY recover from this error condition by using the correct value detected.
- DITAREQ-0390
- DITA processors MAY ignore queries on URI references to DITA resources.
- DITAREQ-0400
- If both
@keyrefand@hrefattributes are specified on an element, the@hrefvalue MUST be used as a fallback address when the key name is undefined. - DITAREQ-0410
- If both
@conkeyrefand@conrefattributes are specified on an element, the@conrefvalue MUST be used as a fallback address when the key name is undefined. - DITAREQ-0420
- Processors SHOULD perform conditional processing before determining the effective key definitions.
- DITAREQ-0430
- If a topic that contains key references is reused in multiple key scopes within a given root map such that its references resolve differently in each use context, processors MUST produce multiple copies of the source topic in resolved output for each distinct set of effective key definitions that are referenced by the topic.
- DITAREQ-0440
- If it is an error for the element to be empty, an implementation MAY give an error message; it also MAY recover from this error condition by leaving the key reference element empty.
- DITAREQ-0450
- Processors MAY impose reasonable limits on the number of intermediate key references that they will resolve.
- DITAREQ-0460
- Processors SHOULD support at least three levels of key references.
- DITAREQ-0470
- Processors MUST resolve variable text
that is defined using keys by using the following sequence:
- Effective text content is taken from the
<keytext>element. - Effective text content is taken from the
<titlealt>element with@title-roleset to linking. - Effective text content is taken from the
<titlealt>element with@title-roleset to navigation. - Effective text content is taken from the
<titlealt>element with@title-roleset to a processor-recognized value. - Effective text content is taken from the title of the referenced document, if available.
- Effective text content is determined by the processor.
- Effective text content is taken from the
- DITAREQ-0480
- When the effective content for a key reference element results in invalid elements, those elements SHOULD be generalized to produce a valid result.
- DITAREQ-0490
- A processor MAY give an
error message when it encounters the following error conditions:
- An
<indexterm>element contains an<index-see>element, and the publication contains one or more<indexterm>elements with matching textual content. - Both
<index-see>and<index-see-also>elements within the same<indexterm>element.
<index-see>element as an<index-see-also>element. - An
- DITAREQ-0500
- I think we cannot make this a stronger statement here than MAY:
- DITAREQ-0510
- Processors that support index ranges SHOULD do the following:
- Match
@startand@endattributes by a character-by-character comparison with all characters significant and no case folding. occurring - Ignore
@startand@endattributes if they occur on an<indexterm>element that has child<indexterm>elements. - When index ranges with the same identifier overlap, the effective range is determined by matching the earliest start element from the set of overlapping ranges with the latest end element from the set of overlapping ranges.
- Handle an end-of-range
<indexterm>element that is nested within one or more<indexterm>elements. The end-of-range<indexterm>element should have no content of its own; if it contains content, that content is ignored. - Ignore unmatched end-of-range
<indexterm>elements.
- Match
- DITAREQ-0520
- Processors SHOULD use the following criteria to match
the content of
<indexterm>elements:- Ignore leading and trailing whitespace, as well as newline characters
- Be case sensitive
- DITAREQ-0530
- (For processors that support indexing) If multiple
<indexterm>elements exist that would result in matching index entries, a processor SHOULD generate only a single index entry, although all locations associated with the<indexterm>element contribute locators. - DITAREQ-0540
- Applications MAY warn users if more than one element attempts to replace a single target.
- DITAREQ-0550
- The start and end elements of a range MUST be of the same type as the referencing element or generalizable to the referencing element.
- DITAREQ-0560
- The start and end elements in a range MUST share the same parent, and the start element MUST precede the end element in document order.
- DITAREQ-0570
- The parent of the referencing element MUST be the same as the parent of the referenced range or generalizable to the parent of the referencing element.
- DITAREQ-0580
- Processors SHOULD issue a warning when a
@conkeyrefreference cannot be resolved and there is no@conrefattribute to use as a fallback. - DITAREQ-0590
- Processors MAY issue a warning when a
@conkeyrefcannot be resolved to an element and a specified@conrefis used as a fallback. - DITAREQ-0600
- When pulling or pushing content with the conref mechanism, processors resolving conrefs SHOULD tolerate specializations of valid elements.
- DITAREQ-0610
- Processors MAY generalize elements in the pushed or pulled content fragment as needed for the resolving context.
- DITAREQ-0620
- A conref processor SHOULD NOT permit resolution of a reuse relationship that could be rendered invalid under the rules of either the reused or reusing content.
- DITAREQ-0630
- If the final resolved element (after the complete resolution of any conref chain) has an attribute with the "-dita-use-conref-target" value, that element MUST be treated as equivalent to having that attribute unspecified.
- DITAREQ-0640
- When the address is a direct URI reference of any form other than a same-topic fragment identifier, processors MUST resolve it relative to the source document that contains the original URI reference.
- DITAREQ-0650
- When the address is a same-topic fragment identifier, processors MUST resolve it relative to the location of the content reference (referencing context).
- DITAREQ-0660
- When the address is a key reference, processors MUST resolve it relative to the location of the content reference (referencing context).
- DITAREQ-0670
- Processors SHOULD be able to perform filtering and
flagging using the following attributes:
@props,@audience,@deliveryTarget,@platform,@product, and@otherprops. - DITAREQ-0680
- The
@propsattribute can be specialized to create new attributes, and processors SHOULD be able to perform conditional processing on specializations of@props. - DITAREQ-0690
- In addition to filtering, applications MAY support flagging at the branch level based on the referenced DITAVAL documents.
- DITAREQ-0700
- Processors SHOULD report an error in such cases.
- DITAREQ-0710
- Processors MAY recover by using an alternate naming scheme for the conflicting topics.
- DITAREQ-0720
- A processor MAY consider this form of equivalence when determining if two references to the same resource should be reported as an error.
- DITAREQ-0730
- The full effects of the branch filtering process MUST be calculated by processors before they construct the effective map and key scope structure.
- DITAREQ-0740
- Processors that perform sorting SHOULD explicitly document how the base sort phrase is determined for a given element.
- DITAREQ-0750
- When a
<sort-as>element is specified, processors that sort the containing element MUST construct the effective sort phrase by prepending the content of the<sort-as>element to the base sort phrase. - DITAREQ-0760
- For attributes within a map, the following processing order MUST occur:
- The
@conrefand@keyrefattributes are evaluated. - The explicit values specified in the document instance are evaluated. For
example, a
<topicref>element with the@tocattribute set to "no" will use that value. - The default or fixed attribute values are evaluated. For example, the
@tocattribute on the<reltable>element has a default value of "no". - The default values that are supplied by a controlled values file are evaluated.
- The attributes cascade.
- The processing-supplied default values are applied.
- After the attributes are resolved within the map, they cascade to referenced maps.
Note (non-normative):The processing-supplied default values do not cascade to other maps. For example, most processors will supply a default value of
toc="yes"when no@tocattribute is specified. However, a processor-supplied default oftoc="yes"MUST NOT override a value oftoc="no"that is set on a referenced map. If thetoc="yes"value is explicitly specified, is given as a default through a DTD, XSD, RNG, or controlled values file, or cascades from a containing element in the map, it MUST override atoc="no"setting on the referenced map. See ../map-to-map-cascading-of-metadata.html for more details. - Repeat steps ../dita-2.0-specification.aggregated.html#concept_afm_sz2_t3b__common-start to ../dita-2.0-specification.aggregated.html#concept_afm_sz2_t3b__common-end for each referenced map.
- The attributes cascade within each referenced map.
- The processing-supplied default values are applied within each referenced map.
- Repeat the process for maps referenced within the referenced maps.
- The
- DITAREQ-0770
- While the DITA specification only defines coding requirements for DTD and RELAX NG, conforming DITA documents MAY use other document-type constraint languages, such as XSD or Schematron.
- DITAREQ-0780
- With two exceptions, a document-type shell MUST NOT directly define element or attribute types; it only includes vocabulary and element-configuration modules (constraint and expansion).
- DITAREQ-0790
- Document-type shells that are not provided by OASIS MUST have a unique public identifier, if public identifiers are used.
- DITAREQ-0800
- Document-type shells that are not provided by OASIS MUST NOT indicate OASIS as the owner.
- DITAREQ-0810
- The public identifier or URN for such document-type shells SHOULD reflect the owner or creator of the document-type shell.
- DITAREQ-0820
- Structural modules based on topic MAY define additional topic types that are then allowed to occur as subordinate topics within the top-level topic.
- DITAREQ-0830
- Domain elements intended for use in topics MUST ultimately be specialized from elements that are defined in the topic module.
- DITAREQ-0840
- Domain elements intended for use in maps MUST ultimately be specialized from elements defined by or used in the map module.
- DITAREQ-0850
- Every DITA element (except the
<dita>element that is used as the root of a ditabase document) MUST declare a@classattribute. - DITAREQ-0860
- When the
@classattribute is declared in an XML grammar, it MUST be declared with a default value. - DITAREQ-0870
- In order to support generalization round-tripping (generalizing specialized content into a generic form and then returning it to the specialized form) the default value MUST NOT be fixed.
- DITAREQ-0880
- A vocabulary module MUST NOT change the
@classattribute for elements that it does not specialize, but simply reuses by reference from more generic levels. - DITAREQ-0890
- Authors SHOULD NOT modify the
@classattribute. - DITAREQ-0900
- Each specialization of the
@propsand@baseattributes MUST provide a token for use by the@specializationsattribute. - DITAREQ-0910
- When generalizing for round-tripping, the
@classattribute and@specializationsattribute SHOULD retain the original specialized values in the generalized instance document. - DITAREQ-0920
- A generalization processor SHOULD be able to handle cases
where it is given:
- Only source modules for generalization (in which case the designated source types are generalized to topic or map)
- Only target modules for generalization (in which case all descendants of each target are generalized to that target)
- Both (in which case only the specified descendants of each target are generalized to that target)
- DITAREQ-0930
- When renaming elements during round-trip generalization, the generalization processor SHOULD preserve the values of all attributes.
- DITAREQ-0940
- When renaming
elements during one-way or migration generalization, the process SHOULD preserve the values of all attributes except the
@classattribute, which is supplied by the target document type. - DITAREQ-0950
- Specialization-aware processors MUST process both the specialized and generalized forms of an attribute as equivalent in their values.
- DITAREQ-0960
- A single element MUST NOT contain both generalized and specialized values for the same attribute.
- DITAREQ-0970
- When possible, generalizing processes SHOULD detect invalid generalization target combinations and report them as errors.
- DITAREQ-0980
- Processors SHOULD render the content of the
<shortdesc>element as the initial paragraph of the topic. - DITAREQ-0990
- When processors generate link previews that are based on the map
context, they SHOULD use the
content of the
<shortdesc>that is located in the map rather than the<shortdesc>that is located in the DITA topic. - DITAREQ-1000
- However, when processors
render the topic itself, they SHOULD use the content of the
<shortdesc>element that is located in the DITA topic. - DITAREQ-1010
- Processors SHOULD support the
following tokens for the
@title-roleattribute:linking- Specifies that the content of the
<titlealt>element contains the title for use in references to the resources generated from DITA map structures, such as hierarchical parent/child/sibling links and links generated from relationship tables. In addition, this is the fallback alternative title fornavigationandsearchroles. Custom title roles meant for use in link generation should also use this as a fallback. navigation- Specifies that the content of the
<titlealt>element contains the title for use in tables of content and other navigation aids. In some cases, when processing a<topicref>that has no@href, this is also used as the title of the generated topic, if applicable. If not present, this role is fulfilled by thelinkingrole. search- Specifies that the content of the
<titlealt>element contains a title for use in search results for systems that support content search. If not present, this role is fulfilled by thelinkingrole. subtitle- Specifies that the content of the
<titlealt>element contains a subtitle for the document. hint- Specifies that the content of the
<titlealt>element contains a hint about the referenced resource. This is intended for the benefit of map authors; it does not have an effect on processing or output. - -dita-use-conref-target
- See ../../../archSpec/base/ditauseconreftarget.html for more information.
- DITAREQ-1020
- Alternative titles with the
@title-roleattribute set to tokens that are not recognized by the processor SHOULD be ignored and not appear in output. - DITAREQ-1030
- When used in conjunction with
<fig>or<table>elements, processors SHOULD consider the content of<desc>elements to be part of the content flow. - DITAREQ-1040
- By default, processors SHOULD NOT render
<draft-comment>elements. - DITAREQ-1050
- Processors SHOULD provide a mechanism that causes the content of the
<draft-comment>element to be rendered in draft output only. - DITAREQ-1060
- Processors SHOULD treat the presence of more than one
<title>element in a<example>element as an error. - DITAREQ-1070
- Processors SHOULD scale the object when values
are provided for the
@heightand@widthattributes. - DITAREQ-1080
- If a height value is specified and no width value is specified, processors SHOULD scale the width by the same factor as the height.
- DITAREQ-1090
- If a width value is specified and no height value is specified, processors SHOULD scale the height by the same factor as the width.
- DITAREQ-1100
- If both a height value and width value are specified, implementations MAY ignore one of the two values when they are unable to scale to each direction using different factors.
- DITAREQ-1110
- Processors SHOULD support the
@parsevalues text and xml. - DITAREQ-1120
- Processors SHOULD detect the encoding of the referenced
document based on the rules described for the
@encodingattribute. - DITAREQ-1130
- Processors SHOULD preserve the
line breaks and spaces that are present in the content of a
<lines>element. - DITAREQ-1140
- Processors SHOULD render a label for notes.
- DITAREQ-1150
- Processors SHOULD scale the object when values
are provided for the
@heightand@widthattributes. - DITAREQ-1160
- If a height value is specified and no width value is specified, processors SHOULD scale the width by the same factor as the height.
- DITAREQ-1170
- If a width value is specified and no height value is specified, processors SHOULD scale the height by the same factor as the width.
- DITAREQ-1180
- If both a height value and width value are specified, implementations MAY ignore one of the two values when they are unable to scale to each direction using different factors.
- DITAREQ-1190
- When an object cannot be rendered in a meaningful way, processors SHOULD present the contents of the
<fallback>element, if it is present. - DITAREQ-1200
- Processors SHOULD preserve
the line breaks and spaces that are present in the content of a
<pre>element. - DITAREQ-1210
- Processors SHOULD treat the presence of more than one
<title>element in a<section>element as an error. - DITAREQ-1220
- When an audio resource cannot be rendered
in a meaningful way, processors SHOULD present the contents of the
<fallback>element, if it is present. - DITAREQ-1230
- Processors SHOULD scale the video resource when values are provided
for the
@heightand@widthattributes. - DITAREQ-1240
- If a height value is specified and no width value is specified, processors SHOULD scale the width by the same factor as the height.
- DITAREQ-1250
- If a width value is specified and no height value is specified, processors SHOULD scale the height by the same factor as the width.
- DITAREQ-1260
- If both a height value and width value are specified, implementations MAY ignore one of the two values when they are unable to scale to each direction using different factors.
- DITAREQ-1270
- When a video resource cannot be rendered in
a meaningful way, processors SHOULD render the contents of the
<fallback>element, if it is present. - DITAREQ-1280
- Processors SHOULD ignore an
<index-see>element if its parent<indexterm>element contains any<indexterm>children. - DITAREQ-1290
- Processors SHOULD ignore an
<index-see-also>element if its parent<indexterm>element contains any<indexterm>children. - DITAREQ-1300
- When
@appid-roleis set to deliverable-anchor, and the<resourceid>applies to a deliverable, processors SHOULD use the@appidvalue when constructing a URI for the delivered resource. - DITAREQ-1310
- By default, processors SHOULD treat a
<data>element as unknown metadata. - DITAREQ-1320
- The contents of the
<data>element SHOULD NOT be rendered. - DITAREQ-1330
- Processors that recognize a particular
<data>element MAY make use of it to trigger specialized rendering. - DITAREQ-1340
- If a processor cannot render the content, it MAY issue a warning.
- DITAREQ-1350
- Processors MAY recover by using an alternate naming scheme for the conflicting copies.
- DITAREQ-1360
- Processors SHOULD scale the object when values
are provided for the
@heightand@widthattributes. - DITAREQ-1370
- If a height value is specified and no width value is specified, processors SHOULD scale the width by the same factor as the height.
- DITAREQ-1380
- If a width value is specified and no height value is specified, processors SHOULD scale the height by the same factor as the width.
- DITAREQ-1390
- If both a height value and width value are specified, implementations MAY ignore one of the two values when they are unable to scale to each direction using different factors.
- DITAREQ-1400
- When a map that contains a
<topicgroup>element with a navigation title is used to generate publication output, processors MUST ignore the navigation title and MAY issue an error message. - DITAREQ-1410
- Processors SHOULD generate a warning if a navigation
title is not specified on a
<topichead>element. - DITAREQ-1420
- Processors SHOULD expect to encounter
<sort-as>elements in the above locations. - DITAREQ-1430
- Processors that sort
SHOULD use the following precedence rules:
- A
<sort-as>element that is specified in a title takes precedence over a<sort-as>element that is specified as a child of the topic prolog. - Except for instances in the topic prolog, processors only apply
<sort-as>elements that are either a direct child of the element to be sorted or a direct child of the title- or label-defining element of the element to be sorted. - When an element contains multiple, direct-child,
<sort-as>elements, the first direct-child<sort-as>element in document order takes precedence. -
It is an error if there is more than one
<sort-as>child for a given<indexterm>element. - Sort phrases are determined after filtering and content reference resolution occur.
- A
- DITAREQ-1440
- When a
<sort-as>element is specified, processors that sort the containing element MUST construct the effective sort phrase by prepending the content of the<sort-as>element to the base sort phrase. - DITAREQ-1450
- Processors MUST strip this element from output by default.
- DITAREQ-1460
- For the
@colorand@backcolorattributes on<prop>and<revprop>, processors SHOULD support at least the following values:- The color names listed under the heading "<color>" in the XSL version 1.1 specification
- The associated hex code
- DITAREQ-1470
- For the
@styleattribute on<rev>and<revprop>, processors SHOULD support the following tokens:- bold
- double-underline
- italics
- overline
- underline
- DITAREQ-1480
- In addition, processors MAY support proprietary tokens
for the
@styleattribute. - DITAREQ-1490
- Such tokens SHOULD have a processor-specific prefix to identify them as proprietary.
- DITAREQ-1500
- If a processor encounters an unsupported style token, it MAY issue a warning, and it MAY render content that is flagged with such a style token by using some default formatting.
- DITAREQ-1510
- For the
@colorand@backcolorattributes on<prop>and<revprop>, processors SHOULD support at least the following values:- The color names listed under the heading "<color>" in the XSL version 1.1 specification
- The associated hex code
- DITAREQ-1520
- For the
@styleattribute on<rev>and<revprop>, processors SHOULD support the following tokens:- bold
- double-underline
- italics
- overline
- underline
- DITAREQ-1530
- In addition, processors MAY support proprietary tokens
for the
@styleattribute. - DITAREQ-1540
- Such tokens SHOULD have a processor-specific prefix to identify them as proprietary.
- DITAREQ-1550
- If a processor encounters an unsupported style token, it MAY issue a warning, and it MAY render content that is flagged with such a style token by using some default formatting.
- DITAREQ-1560
- In such cases processors MAY provide an error or warning message.
- DITAREQ-1570
- Any implementation that supports a feature MUST conform to all rules laid out in the section that describes the feature.
- DITAREQ-1580
- Conforming DITA implementations SHOULD include a conformance statement that gives the version of the DITA specification that is supported, indicate if all features from the list above are supported, and indicate that all normative rendering rules are supported.
- DITAREQ-1590
- If only a subset of features is supported, implementations SHOULD indicate which features are (or are not) supported.
- DITAREQ-1600
- If an implementation supports rendering DITA elements but does not render all elements as described above, that application SHOULD indicate which elements are (or are not) supported.
- DITAREQ-1610
- However, any application that renders content references MUST conform to the rules described in../../archSpec/base/conref.html.
- DITAREQ-1620
- An implementation that does not support a particular feature MUST be prepared to interoperate with other implementations that do support the feature.
- DITAREQ-1630
- A DITA document that refers to document type shells distributed by OASIS MUST be valid according to both the grammar files and any assertions provided in the language reference.
- DITAREQ-1640
- If a DITA document refers to a custom document type shell, that shell MUST also conform to the rules laid out in X.X.X.X Rules for document-type shells.
- DITAREQ-1650
- If a DITA document's custom document type shell includes constraints, that shell MUST also conform to the rules laid out in X.X.X.X Constraint rules
- DITAREQ-1660
- If a DITA document uses specialized elements or attributes, those elements or attributes MUST also conform to the rules laid out in X.X.X Specialization rules for element types, X.X.X Specialization rules for attributes, and X.X.X Class attribute rules and syntax.