Spec terminology: Implementation-dependent / implementation-defined

Since this is a general remark regarding the whole spec, I send it to the list:

While reading comments to the current review round, I stumbled across the termn “implementation dependent” and my instant impulse is to write it with a hyphen. Then I learned that it is good English usage to write it with a hyphen, if that compound adjective acts as a modifier (“implementation-defined behavior”) vs. its use after the noun that is refers to (“behavior is implementation defined”). Interesting, but sideshow.

My real question is about the definitions of the terms “implementation-specific”, “implementation-dependent”, and “information-defined”. And I’m referring to work draft 15 from Nov 23 here.

The term “implementation-specific” is used once:

In 5.3.1.1 Merging of cascading attributes: cascade=”nomerge”: “Tokens can apply to a set of attributes, specified as part of the @cascade value. In that case, the syntax

for specifying those values consists of the implementation-specific token, followed by a parenthetical

group that uses the same syntax as groups within the @audience, @platform, @product, and

@otherprops attributes.”

The term “implementation-dependent” is used twice:

In 7.2.7 (Merging index elements): “It is implementation-dependent as to whether processors consider the presence of phrase-level markup

within <indexterm> elements when performing a matching operation.”

…and in 10.5.1.24 (<source>), processing expectations : “It is implementation-dependent what it means when the element has both content and an attribute-based

reference to another resource.”

The term “implementation-defined” is not used at all.

What I’m missing here are definitions of these terms.

Now, I reckon that probably everyone has a direct understanding of “implementation-specific”, namely that the matter described (may|should|…) is specific to a particular implementation to set it apart from another implementation, which (may|should|…) implement it differently.

“Implementation-dependent” is being used in different ways. It can help to distinguish between “implementation-defined” and “implementation-dependent”. I guess that W3C specs are not necessarily a guideline for the TC, but this is what is being used for the latest edition of XSL 2.0 (https://www.w3.org/TR/2021/REC-xslt20-20210330/):

[Definition: In this specification, the term implementation-defined refers to a feature where the implementation is allowed some flexibility, and where the choices made by the implementation must be described in documentation that accompanies any conformance claim.]

[Definition: The term implementation-dependent refers to a feature where the behavior may vary from one implementation to another, and where the vendor is not expected to provide a full specification of the behavior.] (This might apply, for example, to limits on the size of source documents that can be transformed.)

This raises some questions (at least for me):

Is there a reason why the terms used “i.-specific” and “i.-dependent” are not defined in the spec?
If not, is it advisable to refer to a W3C spec for a definition, if that matches the use of the term in the DITA spec?
Are there any more places, where these terms perhaps should be used?

If that has been discussed in the past, then I’m sorry that I’m not aware of that, but I think, it’s the right time to ask these questions. And I hope, I’m not opening a can of worms here…

Thanks,

Frank

dita message