Aggregated RFC-2119 statements
This section is non-normative.
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
@href
attribute 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
- It is an error for two source topics to replace the same element.
- DITAERR-0070
- The conref push function does not provide the ability to push
a range of elements, so it is an error to specify the
@conrefend
attribute together with the@conaction
attribute. - DITAERR-0080
- When encountering the following error conditions, an implementation can optionally issue an error message.
- DITAERR-0090
- It is an error if
<ditavalref>
-driven branch cloning results in multiple copies of a topic that have the same resolved name. - DITAERR-0100
- Processors SHOULD report an error in such cases.
- DITAERR-0110
- A processor MAY consider this form of equivalence when determining if two references to the same resource should be reported as an error.
- DITAERR-0120
- This saves considerable time and effort, reduces error, enforces consistency, and makes interoperability possible.
- DITAERR-0130
- It is an error if the root element matches a specified
source but its
@class
attribute does not contain the target. - DITAERR-0140
- It is an error if the last value in the
@class
attribute matches a specified source but the previous values do not include the target. - DITAERR-0150
- 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-0160
- Processors SHOULD treat the presence of more than one
<title>
element in a<example>
element as an error. - DITAERR-0170
- Processors SHOULD treat the presence of more than one
<title>
element in a<section>
element as an error. - DITAERR-0180
- 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-0190
- 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-0200
- 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-0210
- It is an error if the value of this attribute is not an unsigned integer.
- DITAERR-0220
- In this case, the implementation might give an error message and might recover by ignoring this attribute.
- DITAERR-0230
- 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-0240
- It is an error if there is more
than one
<sort-as>
child for a given<indexterm>
element. - DITAERR-0250
- The following markup in a DITAVAL document is an error condition:
- More than one
<prop>
element with no@att
attribute - More than one
<prop>
element with the same@att
attribute and no value - More than one
<prop>
element with the same@att
attribute and same@value
- More than one
- DITAERR-0260
- It is an error to include more than one
<revprop>
element with the same@val
attribute. - DITAERR-0270
- Recovery from this error is implementation dependent.
- DITAERR-0280
- In such cases processors MAY provide an error or warning message.
- DITAERR-0290
- It is an error to use
parse="xml"
anywhere other than within<foreign>
or a specialization thereof. - DITAERR-0300
- It is an error to use
parse="xml"
anywhere other than within<foreign>
or a specialization thereof. - DITAERR-0310
- 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-0320
- 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.
Implementation dependent statements
- DITAIMP-0010
- The result is implementation specific.
- DITAIMP-0020
- Recovery from validation errors is implementation specific.
- DITAIMP-0030
- Implementers MAY define their
own custom, implementation-specific tokens for the
@merge
attribute. - DITAIMP-0040
- 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.
- DITAIMP-0050
- The predefined values for the
@cascade
attribute MUST precede any implementation-specific tokens, for example,cascade="merge appToken:audience"
. - DITAIMP-0060
- These tokens are implementation dependent and might not be supported by other applications.
- DITAIMP-0070
- The details of sorting and grouping are implementation specific.
- DITAIMP-0080
- However, the details of footnote processing and formatting are implementation dependent.
- DITAIMP-0090
- The available height is implementation dependent, but if feasible, it is suggested to be the page or table cell height or some other reasonable value.
- DITAIMP-0100
- The available height is implementation dependent, but if feasible, it is suggested to be the page (or table cell) height or some other reasonable value.
- DITAIMP-0110
- Recovery from this error is implementation dependent.
- DITAIMP-0120
- Processors can also define custom, implementation-specific tokens for this attribute.
- DITAIMP-0130
- Processors can also define custom, implementation-specific tokens for this attribute.
- DITAIMP-0140
- The necessity and uses of
@encoding
for non-standard values of@parse
are implementation-dependent. - DITAIMP-0150
- Processors can also define custom, implementation-specific tokens for this attribute.
- DITAIMP-0160
- Processors can also define custom, implementation-specific tokens for this attribute.
- DITAIMP-0170
- The necessity and uses of
@encoding
for non-standard values of@parse
are implementation-dependent.
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:lang
attribute, a processor SHOULD assume a default value. - DITAREQ-0040
- When a
@conref
or@conkeyref
attribute is used to include content from one element into another, the processor MUST use the effective value of the@xml:lang
attribute 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:lang
attribute. - 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
@conref
and@keyref
attributes are evaluated. - The explicit values specified in the document instance are
evaluated. For example, a
<topicref>
element with the@toc
attribute set to "no" will use that value. - The default or fixed attribute values are evaluated. For example, the
@toc
attribute 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@toc
attribute 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
@merge
attribute 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
@merge
attribute. - 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
@cascade
attribute 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
@chunk
attribute. - DITAREQ-0260
- When the
@chunk
attribute results in more or fewer documents based on thecombine
orsplit
tokens, 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
@chunk
attribute 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
@id
attributes for all elements SHOULD be unique. - DITAREQ-0300
- When two elements
within a map have the same value for the
@id
attribute, 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
@format
attribute, 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
@href
attribute MUST be a valid URI reference [RFC 3986]. - DITAREQ-0340
- If the value of the
@href
attribute 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
@type
attribute 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
@keyref
and@href
attributes are specified on an element, the@href
value MUST be used as a fallback address when the key name is undefined. - DITAREQ-0410
- If both
@conkeyref
and@conref
attributes are specified on an element, the@conref
value 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-role
set to linking. - Effective text content is taken from the
<titlealt>
element with@title-role
set to navigation. - Effective text content is taken from the
<titlealt>
element with@title-role
set 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
- Processors that support index ranges SHOULD do the following:
- Match
@start
and@end
attributes by a character-by-character comparison with all characters significant and no case folding occurring. - Ignore
@start
and@end
attributes if they occur on an<indexterm>
element that has child<indexterm>
elements. - 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. - When index ranges with the same identifier overlap, the effective range is determined by matching the earliest start-of-range element from the set of overlapping ranges with the latest end-of-range element from the set of overlapping ranges.
- An unmatched start-of-range element is
treated as a simple
<indexterm>
element. - Ignore unmatched end-of-range
<indexterm>
elements.
- Match
- DITAREQ-0500
- 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-0510
- 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-0520
- The parent of the referencing element MUST be the same type as the parent of the referenced range or generalizable to the parent of the referencing element.
- DITAREQ-0530
- Applications MAY warn users if more than one element attempts to replace a single target.
- DITAREQ-0540
- When pulling or pushing content with the conref mechanism, processors resolving conrefs SHOULD tolerate specializations of valid elements.
- DITAREQ-0550
- Processors MAY generalize elements in the pushed or pulled content fragment as needed for the resolving context.
- DITAREQ-0560
- 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-0570
- When resolving
@conkeyref
attributes, processors SHOULD issue a warning when a@conkeyref
reference cannot be resolved and there is no@conref
attribute to use as a fallback. - DITAREQ-0580
- Processors
MAY issue a warning when a
@conkeyref
cannot be resolved to an element and a specified@conref
is used as a fallback. - DITAREQ-0590
- 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-0600
- 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-0610
- When the address is a same-topic fragment identifier, processors MUST resolve it relative to the location of the content reference (referencing context).
- DITAREQ-0620
- When the address is a key reference, processors MUST resolve it relative to the location of the content reference (referencing context).
- DITAREQ-0630
- Processors SHOULD be able to perform filtering and
flagging using the following attributes:
@props
,@audience
,@deliveryTarget
,@platform
,@product
, and@otherprops
. - DITAREQ-0640
- The
@props
attribute can be specialized to create new attributes, and processors SHOULD be able to perform conditional processing on specializations of@props
. - DITAREQ-0650
- In addition to filtering, applications MAY support flagging at the branch level based on the referenced DITAVAL documents.
- DITAREQ-0660
- Processors SHOULD report an error in such cases.
- DITAREQ-0670
- Processors MAY recover by using an alternate naming scheme for the conflicting topics.
- DITAREQ-0680
- A processor MAY consider this form of equivalence when determining if two references to the same resource should be reported as an error.
- DITAREQ-0690
- The full effects of the branch filtering process MUST be calculated by processors before they construct the effective map and key scope structure.
- DITAREQ-0700
- Processors that perform sorting SHOULD explicitly document how the base sort phrase is determined for a given element.
- DITAREQ-0710
- 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-0720
- For attributes within a map, the following processing order MUST occur:
- The
@conref
and@keyref
attributes are evaluated. - The explicit values specified in the document instance are evaluated. For
example, a
<topicref>
element with the@toc
attribute set to "no" will use that value. - The default or fixed attribute values are evaluated. For example, the
@toc
attribute 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@toc
attribute 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-0730
- 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-0740
- 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-0750
- Document-type shells that are not provided by OASIS MUST have a unique public identifier, if public identifiers are used.
- DITAREQ-0760
- Document-type shells that are not provided by OASIS MUST NOT indicate OASIS as the owner.
- DITAREQ-0770
- The public identifier or URN for such document-type shells SHOULD reflect the owner or creator of the document-type shell.
- DITAREQ-0780
- 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-0790
- Domain elements intended for use in topics MUST ultimately be specialized from elements that are defined in the topic module.
- DITAREQ-0800
- Domain elements intended for use in maps MUST ultimately be specialized from elements defined by or used in the map module.
- DITAREQ-0810
- Every DITA element (except the
<dita>
element that is used as the root of a ditabase document) MUST declare a@class
attribute. - DITAREQ-0820
- When the
@class
attribute is declared in an XML grammar, it MUST be declared with a default value. - DITAREQ-0830
- 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-0840
- A vocabulary module MUST NOT change the
@class
attribute for elements that it does not specialize, but simply reuses by reference from more generic levels. - DITAREQ-0850
- Authors SHOULD NOT modify the
@class
attribute. - DITAREQ-0860
- Each specialization of the
@props
and@base
attributes MUST provide a token for use by the@specializations
attribute. - DITAREQ-0870
- When generalizing for round-tripping, the
@class
attribute and@specializations
attribute SHOULD retain the original specialized values in the generalized instance document. - DITAREQ-0880
- 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-0890
- When renaming elements during round-trip generalization, the generalization processor SHOULD preserve the values of all attributes.
- DITAREQ-0900
- When renaming
elements during one-way or migration generalization, the process SHOULD preserve the values of all attributes except the
@class
attribute, which is supplied by the target document type. - DITAREQ-0910
- Specialization-aware processors MUST process both the specialized and generalized forms of an attribute as equivalent in their values.
- DITAREQ-0920
- A single element MUST NOT contain both generalized and specialized values for the same attribute.
- DITAREQ-0930
- When possible, generalizing processes SHOULD detect invalid generalization target combinations and report them as errors.
- DITAREQ-0940
- Processors SHOULD render the content of the
<shortdesc>
element as the initial paragraph of the topic. - DITAREQ-0950
- 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-0960
- However, when processors
render the topic itself, they SHOULD use the content of the
<shortdesc>
element that is located in the DITA topic. - DITAREQ-0970
- Processors SHOULD support the
following tokens for the
@title-role
attribute: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 fornavigation
andsearch
roles. 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 thelinking
role. 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 thelinking
role. 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-0980
- Alternative titles with the
@title-role
attribute set to tokens that are not recognized by the processor SHOULD be ignored and not appear in output. - DITAREQ-0990
- 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-1000
- By default, processors SHOULD NOT render
<draft-comment>
elements. - DITAREQ-1010
- Processors SHOULD provide a mechanism that causes the content of the
<draft-comment>
element to be rendered in draft output only. - DITAREQ-1020
- Processors SHOULD treat the presence of more than one
<title>
element in a<example>
element as an error. - DITAREQ-1030
- Processors SHOULD scale the object when values
are provided for the
@height
and@width
attributes. - DITAREQ-1040
- 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-1050
- 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-1060
- 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-1070
- Processors SHOULD support the
@parse
values text and xml. - DITAREQ-1080
- Processors SHOULD detect the encoding of the referenced
document based on the rules described for the
@encoding
attribute. - DITAREQ-1090
- Processors SHOULD preserve the
line breaks and spaces that are present in the content of a
<lines>
element. - DITAREQ-1100
- Processors SHOULD render a label for notes.
- DITAREQ-1110
- Processors SHOULD scale the object when values
are provided for the
@height
and@width
attributes. - DITAREQ-1120
- 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-1130
- 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-1140
- 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-1150
- When an object cannot be rendered in a meaningful way, processors SHOULD present the contents of the
<fallback>
element, if it is present. - DITAREQ-1160
- Processors SHOULD preserve
the line breaks and spaces that are present in the content of a
<pre>
element. - DITAREQ-1170
- Processors SHOULD treat the presence of more than one
<title>
element in a<section>
element as an error. - DITAREQ-1180
- 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-1190
- Processors SHOULD scale the video resource when values are provided
for the
@height
and@width
attributes. - DITAREQ-1200
- 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-1210
- 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-1220
- 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-1230
- 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-1240
- Processors SHOULD ignore an
<index-see>
element if its parent<indexterm>
element contains any<indexterm>
children. - DITAREQ-1250
- Processors SHOULD ignore an
<index-see-also>
element if its parent<indexterm>
element contains any<indexterm>
children. - DITAREQ-1260
- When
@appid-role
is set to deliverable-anchor, and the<resourceid>
applies to a deliverable, processors SHOULD use the@appid
value when constructing a URI for the delivered resource. - DITAREQ-1270
- By default, processors SHOULD treat a
<data>
element as unknown metadata. - DITAREQ-1280
- The contents of the
<data>
element SHOULD NOT be rendered. - DITAREQ-1290
- Processors that recognize a particular
<data>
element MAY make use of it to trigger specialized rendering. - DITAREQ-1300
- If a processor cannot render the content, it MAY issue a warning.
- DITAREQ-1310
- Processors MAY recover by using an alternate naming scheme for the conflicting copies.
- DITAREQ-1320
- Processors SHOULD scale the object when values
are provided for the
@height
and@width
attributes. - DITAREQ-1330
- 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-1340
- 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-1350
- 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-1360
- 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-1370
- Processors SHOULD generate a warning if a navigation
title is not specified on a
<topichead>
element. - DITAREQ-1380
- Processors SHOULD expect to encounter
<sort-as>
elements in the above locations. - DITAREQ-1390
- 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-1400
- 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-1410
- Processors MUST strip this element from output by default.
- DITAREQ-1420
- For the
@color
and@backcolor
attributes 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-1430
- For the
@style
attribute on<rev>
and<revprop>
, processors SHOULD support the following tokens:- bold
- double-underline
- italics
- overline
- underline
- DITAREQ-1440
- In addition, processors MAY support proprietary tokens
for the
@style
attribute. - DITAREQ-1450
- Such tokens SHOULD have a processor-specific prefix to identify them as proprietary.
- DITAREQ-1460
- 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-1470
- For the
@color
and@backcolor
attributes 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-1480
- For the
@style
attribute on<rev>
and<revprop>
, processors SHOULD support the following tokens:- bold
- double-underline
- italics
- overline
- underline
- DITAREQ-1490
- In addition, processors MAY support proprietary tokens
for the
@style
attribute. - DITAREQ-1500
- Such tokens SHOULD have a processor-specific prefix to identify them as proprietary.
- DITAREQ-1510
- 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-1520
- In such cases processors MAY provide an error or warning message.
- DITAREQ-1530
- Any implementation that supports a feature MUST conform to all rules laid out in the section that describes the feature.
- DITAREQ-1540
- 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-1550
- If only a subset of features is supported, implementations SHOULD indicate which features are (or are not) supported.
- DITAREQ-1560
- 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-1570
- However, any application that renders content references MUST conform to the rules described in../../archSpec/base/conref.html.
- DITAREQ-1580
- An implementation that does not support a particular feature MUST be prepared to interoperate with other implementations that do support the feature.
- DITAREQ-1590
- 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-1600
- 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-1610
- 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-1620
- 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.