OASIS Darwin Information Typing Architecture (DITA) TC

Robert and I had a chance to discuss this during a spec editors' call on 27 December. Prior to that call, I had searched the spec for all instances of the word implementation, and generated a HTML file that listed them (attached). We don't think we can use the W3C terms and their definitions, as they don't really map well to OASIS normative statements, but certainly want to crisp up the language used in the spec. On first glance, the spec tends to make the following sorts of statements about when something is left up to the implementation: Describing how an implementation should or might respond to an error condition Declaring that something is left entirely up to an implementation, for example, support for a display group attribute Granting permission for an implementation to develop custom values for attributes, for example, a custom value for the @title-role attribute I'll be digging more into this, but thought that folks might: Want to look at the attached HTML file that gives information about where (and to some extent) how the word implementation is used in the spec Have thoughts about this issue or how we might want to define the terms implementation or processor Robert and I looked briefly at the XSLT spec (and liked what we saw), but it was at the end of our 90-minute call and we ran out of time. -- Best, Kris Title: Results Description File Location <li>If both a height value and width value are specified, implementations <term C:Gitspecificationcommonconref-rendering-expectations.dita Start line 18:79 Length: 14 outputclass= RFC-2119 >MAY</term> define their own custom, implementation-specific tokens C:Gitspecificationcommonconref-file.dita Start line 186:70 Length: 14 for the <xmlatt>merge</xmlatt> attribute. To avoid name conflicts between implementations or C:Gitspecificationcommonconref-file.dita Start line 187:83 Length: 14 with future additions to the standard, implementation-specific tokens <term C:Gitspecificationcommonconref-file.dita Start line 188:48 Length: 14 abbreviation for the implementation followed by a colon followed by the token or method C:Gitspecificationcommonconref-file.dita Start line 190:30 Length: 14 value are specified, implementations <term C:Gitspecificationcommonconref-attribute.dita Start line 135:62 Length: 14 this case, the implementation might give an error C:Gitspecificationcommonconref-attribute.dita Start line 340:66 Length: 14 implementation dependent, but if feasible, it is C:Gitspecificationcommonconref-attribute.dita Start line 365:51 Length: 14 <p>However, the details of footnote processing and formatting are implementation dependent. C:Gitspecificationcommon
euse-w-lwdita
euse-fn.dita Start line 99:73 Length: 14 instead od text. The available height is implementation C:Gitspecificationcommon
euse-w-lwdita
euse-image.dita Start line 84:56 Length: 14 <li>If both a height value and width value are specified, implementations <term C:Gitspecificationcommon
euse-w-lwdita
euse-video.dita Start line 42:69 Length: 14 symbol used is implementation specific.</p> C:GitspecificationlangRefasefn.dita Start line 36:26 Length: 14 implementation. It can be used together with the <xmlatt>data</xmlatt> C:GitspecificationlangRefaseobject.dita Start line 62:25 Length: 14 object's implementation, as for <xmlatt>classid</xmlatt>. When specified, C:GitspecificationlangRefaseobject.dita Start line 69:34 Length: 14 implementation as a string. </dd> C:GitspecificationlangRefaseparam.dita Start line 111:19 Length: 14 used:</p><codeblock>&lt;p&gt;A &lt;term&gt;reference implementation&lt;/term&gt; of DITA implements the standard, C:GitspecificationlangRefase erm.dita Start line 26:63 Length: 14 to the implementation.</p> C:GitspecificationlangRefasesimpletable.dita Start line 128:16 Length: 14 <p>DITA implementations often reference images using keys. C:GitspecificationlangRefasekeytext.dita Start line 46:25 Length: 14 <p>An implementation might use this identification to check cross-component dependencies when C:GitspecificationlangRefasecomponent.dita Start line 22:10 Length: 14 some components are installed, but not others. An implementation might use the C:GitspecificationlangRefasecomponent.dita Start line 23:59 Length: 14 <p>It is implementation-dependent what it means when the element has both content and an C:GitspecificationlangRefasesource.dita Start line 25:16 Length: 14 given <xmlelement>indexterm</xmlelement>. An implementation encountering more than one C:GitspecificationlangRefasesort-as.dita Start line 83:58 Length: 14 different default value? How is an implementation supposed to C:GitspecificationlangRefasedefaultSubject.dita Start line 26:46 Length: 14 implementation dependent; in such cases processors <term outputclass= RFC-2119 C:GitspecificationlangRefditavalditaval-revprop.dita Start line 37:17 Length: 14 which are implementation dependent.</li> C:GitspecificationlangRefditavalditaval-val.dita Start line 55:32 Length: 14 implementation-dependent.</p></dd> C:GitspecificationlangRefattributescommonAttributes.dita Start line 284:15 Length: 14 works that comment on or otherwise explain it or assist in its implementation may be C:Gitspecification
esourcesoasis-notices.dita Start line 13:72 Length: 14 that would necessarily be infringed by implementations of this OASIS Committee Specification C:Gitspecification
esourcesoasis-notices.dita Start line 28:48 Length: 14 ownership of any patent claims that would necessarily be infringed by implementations of C:Gitspecification
esourcesoasis-notices.dita Start line 33:79 Length: 14 other rights that might be claimed to pertain to the implementation or use of the technology C:Gitspecification
esourcesoasis-notices.dita Start line 39:62 Length: 14 its official outputs. OASIS welcomes reference to, and implementation and use of, C:Gitspecification
esourcesoasis-notices.dita Start line 53:64 Length: 14 or undefined values. Recovery from validation errors is implementation specific.</p> C:GitspecificationarchSpecaseinding-controlled-values-to-attribute.dita Start line 43:69 Length: 14 consists of the implementation-specific token, followed by a parenthetical group that C:GitspecificationarchSpecasemerging-of-cascading-attributes.dita Start line 21:29 Length: 14 outputclass= RFC-2119 >MUST</term> precede any implementation-specific tokens, for C:GitspecificationarchSpecasemerging-of-cascading-attributes.dita Start line 28:64 Length: 14 not valid in bookmap and might not be understandable by processors. The result is implementation C:GitspecificationarchSpecasecascading-of-roles-in-specialized-maps.dita Start line 59:86 Length: 14 attribute. These tokens are necessarily implementation dependent and might not be supported C:GitspecificationarchSpecasechunk-attribute-other-tokens.dita Start line 6:49 Length: 14 implementations processing <xmlatt>chunk</xmlatt> to generate files, as long as the rendered result C:GitspecificationarchSpecaseexamples-of-chunking.dita Start line 12:1 Length: 14 is split or combined as described. If generating files, actual file names are implementation C:GitspecificationarchSpecaseexamples-of-chunking.dita Start line 13:79 Length: 14 <xmlelement>topichead</xmlelement>elements in implementation-specific ways Was that C:GitspecificationarchSpecaseexample-chunk-combine-group.dita Start line 41:59 Length: 14 <li>In some cases, an implementation might treat the <xmlelement>topichead</xmlelement> element as C:GitspecificationarchSpecaseexample-chunk-ignored.dita Start line 53:23 Length: 14 from this map, or to the individual topics in the other context. Implementations will have to guess C:GitspecificationarchSpecaseexample-chunk-managing-links.dita Start line 100:66 Length: 14 for an implementation to define its own way to resolve this ambiguity; however, if a situation C:GitspecificationarchSpecaseexample-chunk-managing-links.dita Start line 119:8 Length: 14 requires both multiple instances of split topics and unambiguous cross-implementation links to those C:GitspecificationarchSpecaseexample-chunk-managing-links.dita Start line 120:72 Length: 14 implementation <term outputclass= RFC-2119 >MAY</term> generate an error message; it <term C:GitspecificationarchSpecase hehrefattribute.dita Start line 21:5 Length: 14 the purpose of creating map-to-map key references (peer maps). An implementation C:GitspecificationarchSpecase hescopeattribute.dita Start line 22:87 Length: 14 <xmlatt>type</xmlatt> attribute value. In this case, an implementation <term C:GitspecificationarchSpecase hetypeattribute.dita Start line 39:67 Length: 14 implementation rules and was moved from the langref to the archspec seciton about keys. Need C:GitspecificationarchSpecase he-key-scope-attribute.dita Start line 25:9 Length: 14 a navigation link. If it is an error for the element to be empty, an implementation C:GitspecificationarchSpecaseprocessing-key-references-general.dita Start line 63:86 Length: 14 implementation specific.</p> C:GitspecificationarchSpecaseindexes.dita Start line 31:5 Length: 14 <p>It is implementation-dependent as to whether processors consider the presence of C:GitspecificationarchSpecasemerging-index-elements.dita Start line 24:18 Length: 14 other implementation strategy.</p> C:GitspecificationarchSpecase heconactionattribute.dita Start line 209:15 Length: 14 <p>When encountering an error condition, an implementation can issue an error message.</p> C:GitspecificationarchSpecase heconrefendattribute.dita Start line 245:51 Length: 14 <p>How this map is rendered is implementation dependent. If this root map is rendered as a C:GitspecificationarchSpecaseexample-multiple-ditavalref-as-child-of-map.dita Start line 73:38 Length: 14 <p>The details of sorting and grouping are implementation specific. Processors might provide C:GitspecificationarchSpecasesort-as-processing.dita Start line 37:46 Length: 14 <indexterm>design and implementation rules<indexterm>document-type C:GitspecificationarchSpecase
ules-document-type-shells.dita Start line 9:31 Length: 14 <shortdesc>Modularization is at the core of DITA design and implementation. It enables reuse and C:GitspecificationarchSpecasespecialization-modularization.dita Start line 5:62 Length: 14 <indexterm>design and implementation rules<indexterm>element types</indexterm></indexterm> C:GitspecificationarchSpecasespecialization-rules-elements.dita Start line 9:31 Length: 14 <indexterm>design and implementation rules<indexterm>attribute types</indexterm></indexterm> C:GitspecificationarchSpecasespecialization-rules-attributes.dita Start line 9:31 Length: 14 <xmlelement>unknown</xmlelement> element. This is the usual implementation.</li> C:GitspecificationarchSpecasespecialization-including-non-dita-content.dita Start line 24:73 Length: 14 <note rev= 2.0 >For DITA implementations that use RNG-based grammar file, restricting the set of C:GitspecificationarchSpecaseconstraints-overview.dita Start line 52:31 Length: 14 <shortdesc>There are certain rules that apply to the design and implementation of C:GitspecificationarchSpecaseconstraint-rules.dita Start line 5:66 Length: 14 <indexterm>constraints<indexterm>design and implementation rules</indexterm></indexterm> C:GitspecificationarchSpecaseconstraint-rules.dita Start line 10:49 Length: 14 <xmlelement>u</xmlelement>. Her implementation uses RNG for its grammar files.</shortdesc> C:GitspecificationarchSpecaseexample-constrain-a-domain-using-rng.dita Start line 10:41 Length: 14 implementation to use:</p> C:GitspecificationarchSpecaseexample-constrain-a-domain-using-rng.dita Start line 27:11 Length: 14 <shortdesc>There are certain rules that apply to the design and implementation of expansion C:GitspecificationarchSpecaseexpansion-module-rules.dita Start line 5:69 Length: 14 <indexterm>design and implementation rules<indexterm>expansion C:GitspecificationarchSpecaseexpansion-module-rules.dita Start line 10:39 Length: 14 <indexterm>expansion modules<indexterm>design and implementation C:GitspecificationarchSpecaseexpansion-module-rules.dita Start line 12:67 Length: 14 <title>Implementation of element-configuration modules</title> C:GitspecificationarchSpecase
elax-ng-coding-requirements-for-element-configuration-modules.dita Start line 14:20 Length: 14 <shortdesc>An implementation is a conforming implementation of DITA if the implementation meets C:Gitspecificationconformanceconformance.dita Start line 6:17 Length: 14 <shortdesc>An implementation is a conforming implementation of DITA if the implementation meets C:Gitspecificationconformanceconformance.dita Start line 6:48 Length: 14 <shortdesc>An implementation is a conforming implementation of DITA if the implementation meets C:Gitspecificationconformanceconformance.dita Start line 6:78 Length: 14 different processors to produce the same or similar results with little or no reimplementation or C:Gitspecificationconformanceconformance.dita Start line 11:81 Length: 14 <title>4.1 Conformance of DITA implementations</title> C:Gitspecificationconformanceconformance.dita Start line 15:32 Length: 14 implementation that supports a feature <term outputclass= RFC-2119 >MUST</term> conform to all rules C:Gitspecificationconformanceconformance.dita Start line 17:1 Length: 14 <p>Conforming DITA implementations <term outputclass= RFC-2119 >SHOULD</term> include a conformance C:Gitspecificationconformanceconformance.dita Start line 59:20 Length: 14 <p>If only a subset of features is supported, implementations <term outputclass= RFC-2119 C:Gitspecificationconformanceconformance.dita Start line 63:47 Length: 14 >SHOULD</term> indicate which features are (or are not) supported. If an implementation supports C:Gitspecificationconformanceconformance.dita Start line 64:74 Length: 14 <p>Not all DITA features are relevant for all implementations. For example, a DITA editor that does C:Gitspecificationconformanceconformance.dita Start line 67:47 Length: 14 <p>Implementations that support only a subset of DITA features are considered conforming as long as C:Gitspecificationconformanceconformance.dita Start line 72:4 Length: 14 implementation that does not support a particular feature <term outputclass= RFC-2119 >MUST</term> C:Gitspecificationconformanceconformance.dita Start line 74:1 Length: 14 be prepared to interoperate with other implementations that do support the feature.</p> C:Gitspecificationconformanceconformance.dita Start line 75:40 Length: 14 <p>As an implementation detail for key-space-constructing processors, if filtering is applied C:Gitspecification
on-normativeinteroperability-considerations.dita Start line 67:16 Length: 14 implementation is being heavily customized, a customized document type can help isolate and C:Gitspecification
on-normativespeclimits.dita Start line 68:9 Length: 14 implementation of the following DITA 2.0 proposals:</p><ul> C:Gitspecification
on-normative
evision-history.dita Start line 127:25 Length: 14