[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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):
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
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]