[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Implementation-specific, implementation-dependent, etc.
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:
I'll be digging more into this, but thought that folks might:
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.
| Description | File | Location |
|---|---|---|
| <li>If both a height value and width value are specified, implementations <term | C:\Git\specification\common\conref-rendering-expectations.dita |
Start line 18:79 Length: 14 |
| outputclass="RFC-2119">MAY</term> define their own custom, implementation-specific tokens | C:\Git\specification\common\conref-file.dita |
Start line 186:70 Length: 14 |
| for the <xmlatt>merge</xmlatt> attribute. To avoid name conflicts between implementations or | C:\Git\specification\common\conref-file.dita |
Start line 187:83 Length: 14 |
| with future additions to the standard, implementation-specific tokens <term | C:\Git\specification\common\conref-file.dita |
Start line 188:48 Length: 14 |
| abbreviation for the implementation followed by a colon followed by the token or method | C:\Git\specification\common\conref-file.dita |
Start line 190:30 Length: 14 |
| value are specified, implementations <term | C:\Git\specification\common\conref-attribute.dita |
Start line 135:62 Length: 14 |
| this case, the implementation might give an error | C:\Git\specification\common\conref-attribute.dita |
Start line 340:66 Length: 14 |
| implementation dependent, but if feasible, it is | C:\Git\specification\common\conref-attribute.dita |
Start line 365:51 Length: 14 |
| <p>However, the details of footnote processing and formatting are implementation dependent. | C:\Git\specification\common\reuse-w-lwdita\reuse-fn.dita |
Start line 99:73 Length: 14 |
| instead od text. The available height is implementation | C:\Git\specification\common\reuse-w-lwdita\reuse-image.dita |
Start line 84:56 Length: 14 |
| <li>If both a height value and width value are specified, implementations <term | C:\Git\specification\common\reuse-w-lwdita\reuse-video.dita |
Start line 42:69 Length: 14 |
| symbol used is implementation specific.</p> | C:\Git\specification\langRef\base\fn.dita |
Start line 36:26 Length: 14 |
| implementation. It can be used together with the <xmlatt>data</xmlatt> | C:\Git\specification\langRef\base\object.dita |
Start line 62:25 Length: 14 |
| object's implementation, as for <xmlatt>classid</xmlatt>. When specified, | C:\Git\specification\langRef\base\object.dita |
Start line 69:34 Length: 14 |
| implementation as a string. </dd> | C:\Git\specification\langRef\base\param.dita |
Start line 111:19 Length: 14 |
| used:</p><codeblock><p>A <term>reference implementation</term> of DITA implements the standard, | C:\Git\specification\langRef\base\term.dita |
Start line 26:63 Length: 14 |
| to the implementation.</p> | C:\Git\specification\langRef\base\simpletable.dita |
Start line 128:16 Length: 14 |
| <p>DITA implementations often reference images using keys. | C:\Git\specification\langRef\base\keytext.dita |
Start line 46:25 Length: 14 |
| <p>An implementation might use this identification to check cross-component dependencies when | C:\Git\specification\langRef\base\component.dita |
Start line 22:10 Length: 14 |
| some components are installed, but not others. An implementation might use the | C:\Git\specification\langRef\base\component.dita |
Start line 23:59 Length: 14 |
| <p>It is implementation-dependent what it means when the element has both content and an | C:\Git\specification\langRef\base\source.dita |
Start line 25:16 Length: 14 |
| given <xmlelement>indexterm</xmlelement>. An implementation encountering more than one | C:\Git\specification\langRef\base\sort-as.dita |
Start line 83:58 Length: 14 |
| different default value? How is an implementation supposed to | C:\Git\specification\langRef\base\defaultSubject.dita |
Start line 26:46 Length: 14 |
| implementation dependent; in such cases processors <term outputclass="RFC-2119" | C:\Git\specification\langRef\ditaval\ditaval-revprop.dita |
Start line 37:17 Length: 14 |
| which are implementation dependent.</li> | C:\Git\specification\langRef\ditaval\ditaval-val.dita |
Start line 55:32 Length: 14 |
| implementation-dependent.</p></dd> | C:\Git\specification\langRef\attributes\commonAttributes.dita |
Start line 284:15 Length: 14 |
| works that comment on or otherwise explain it or assist in its implementation may be | C:\Git\specification\resources\oasis-notices.dita |
Start line 13:72 Length: 14 |
| that would necessarily be infringed by implementations of this OASIS Committee Specification | C:\Git\specification\resources\oasis-notices.dita |
Start line 28:48 Length: 14 |
| ownership of any patent claims that would necessarily be infringed by implementations of | C:\Git\specification\resources\oasis-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:\Git\specification\resources\oasis-notices.dita |
Start line 39:62 Length: 14 |
| its official outputs. OASIS welcomes reference to, and implementation and use of, | C:\Git\specification\resources\oasis-notices.dita |
Start line 53:64 Length: 14 |
| or undefined values. Recovery from validation errors is implementation specific.</p> | C:\Git\specification\archSpec\base\binding-controlled-values-to-attribute.dita |
Start line 43:69 Length: 14 |
| consists of the implementation-specific token, followed by a parenthetical group that | C:\Git\specification\archSpec\base\merging-of-cascading-attributes.dita |
Start line 21:29 Length: 14 |
| outputclass="RFC-2119">MUST</term> precede any implementation-specific tokens, for | C:\Git\specification\archSpec\base\merging-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:\Git\specification\archSpec\base\cascading-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:\Git\specification\archSpec\base\chunk-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:\Git\specification\archSpec\base\examples-of-chunking.dita |
Start line 12:1 Length: 14 |
| is split or combined as described. If generating files, actual file names are implementation | C:\Git\specification\archSpec\base\examples-of-chunking.dita |
Start line 13:79 Length: 14 |
| <xmlelement>topichead</xmlelement>elements in implementation-specific ways â Was that | C:\Git\specification\archSpec\base\example-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:\Git\specification\archSpec\base\example-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:\Git\specification\archSpec\base\example-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:\Git\specification\archSpec\base\example-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:\Git\specification\archSpec\base\example-chunk-managing-links.dita |
Start line 120:72 Length: 14 |
| implementation <term outputclass="RFC-2119">MAY</term> generate an error message; it <term | C:\Git\specification\archSpec\base\thehrefattribute.dita |
Start line 21:5 Length: 14 |
| the purpose of creating map-to-map key references (peer maps). An implementation | C:\Git\specification\archSpec\base\thescopeattribute.dita |
Start line 22:87 Length: 14 |
| <xmlatt>type</xmlatt> attribute value. In this case, an implementation <term | C:\Git\specification\archSpec\base\thetypeattribute.dita |
Start line 39:67 Length: 14 |
| implementation rules and was moved from the langref to the archspec seciton about keys. Need | C:\Git\specification\archSpec\base\the-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:\Git\specification\archSpec\base\processing-key-references-general.dita |
Start line 63:86 Length: 14 |
| implementation specific.</p> | C:\Git\specification\archSpec\base\indexes.dita |
Start line 31:5 Length: 14 |
| <p>It is implementation-dependent as to whether processors consider the presence of | C:\Git\specification\archSpec\base\merging-index-elements.dita |
Start line 24:18 Length: 14 |
| other implementation strategy.</p> | C:\Git\specification\archSpec\base\theconactionattribute.dita |
Start line 209:15 Length: 14 |
| <p>When encountering an error condition, an implementation can issue an error message.</p> | C:\Git\specification\archSpec\base\theconrefendattribute.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:\Git\specification\archSpec\base\example-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:\Git\specification\archSpec\base\sort-as-processing.dita |
Start line 37:46 Length: 14 |
| <indexterm>design and implementation rules<indexterm>document-type | C:\Git\specification\archSpec\base\rules-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:\Git\specification\archSpec\base\specialization-modularization.dita |
Start line 5:62 Length: 14 |
| <indexterm>design and implementation rules<indexterm>element types</indexterm></indexterm> | C:\Git\specification\archSpec\base\specialization-rules-elements.dita |
Start line 9:31 Length: 14 |
| <indexterm>design and implementation rules<indexterm>attribute types</indexterm></indexterm> | C:\Git\specification\archSpec\base\specialization-rules-attributes.dita |
Start line 9:31 Length: 14 |
| <xmlelement>unknown</xmlelement> element. This is the usual implementation.</li> | C:\Git\specification\archSpec\base\specialization-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:\Git\specification\archSpec\base\constraints-overview.dita |
Start line 52:31 Length: 14 |
| <shortdesc>There are certain rules that apply to the design and implementation of | C:\Git\specification\archSpec\base\constraint-rules.dita |
Start line 5:66 Length: 14 |
| <indexterm>constraints<indexterm>design and implementation rules</indexterm></indexterm> | C:\Git\specification\archSpec\base\constraint-rules.dita |
Start line 10:49 Length: 14 |
| <xmlelement>u</xmlelement>. Her implementation uses RNG for its grammar files.</shortdesc> | C:\Git\specification\archSpec\base\example-constrain-a-domain-using-rng.dita |
Start line 10:41 Length: 14 |
| implementation to use:</p> | C:\Git\specification\archSpec\base\example-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:\Git\specification\archSpec\base\expansion-module-rules.dita |
Start line 5:69 Length: 14 |
| <indexterm>design and implementation rules<indexterm>expansion | C:\Git\specification\archSpec\base\expansion-module-rules.dita |
Start line 10:39 Length: 14 |
| <indexterm>expansion modules<indexterm>design and implementation | C:\Git\specification\archSpec\base\expansion-module-rules.dita |
Start line 12:67 Length: 14 |
| <title>Implementation of element-configuration modules</title> | C:\Git\specification\archSpec\base\relax-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:\Git\specification\conformance\conformance.dita |
Start line 6:17 Length: 14 |
| <shortdesc>An implementation is a conforming implementation of DITA if the implementation meets | C:\Git\specification\conformance\conformance.dita |
Start line 6:48 Length: 14 |
| <shortdesc>An implementation is a conforming implementation of DITA if the implementation meets | C:\Git\specification\conformance\conformance.dita |
Start line 6:78 Length: 14 |
| different processors to produce the same or similar results with little or no reimplementation or | C:\Git\specification\conformance\conformance.dita |
Start line 11:81 Length: 14 |
| <title>4.1 Conformance of DITA implementations</title> | C:\Git\specification\conformance\conformance.dita |
Start line 15:32 Length: 14 |
| implementation that supports a feature <term outputclass="RFC-2119">MUST</term> conform to all rules | C:\Git\specification\conformance\conformance.dita |
Start line 17:1 Length: 14 |
| <p>Conforming DITA implementations <term outputclass="RFC-2119">SHOULD</term> include a conformance | C:\Git\specification\conformance\conformance.dita |
Start line 59:20 Length: 14 |
| <p>If only a subset of features is supported, implementations <term outputclass="RFC-2119" | C:\Git\specification\conformance\conformance.dita |
Start line 63:47 Length: 14 |
| >SHOULD</term> indicate which features are (or are not) supported. If an implementation supports | C:\Git\specification\conformance\conformance.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:\Git\specification\conformance\conformance.dita |
Start line 67:47 Length: 14 |
| <p>Implementations that support only a subset of DITA features are considered conforming as long as | C:\Git\specification\conformance\conformance.dita |
Start line 72:4 Length: 14 |
| implementation that does not support a particular feature <term outputclass="RFC-2119">MUST</term> | C:\Git\specification\conformance\conformance.dita |
Start line 74:1 Length: 14 |
| be prepared to interoperate with other implementations that do support the feature.</p> | C:\Git\specification\conformance\conformance.dita |
Start line 75:40 Length: 14 |
| <p>As an implementation detail for key-space-constructing processors, if filtering is applied | C:\Git\specification\non-normative\interoperability-considerations.dita |
Start line 67:16 Length: 14 |
| implementation is being heavily customized, a customized document type can help isolate and | C:\Git\specification\non-normative\speclimits.dita |
Start line 68:9 Length: 14 |
| implementation of the following DITA 2.0 proposals:</p><ul> | C:\Git\specification\non-normative\revision-history.dita |
Start line 127:25 Length: 14 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]