[OASIS Issue Tracker] Updated: (OFFICE-3442) Need to define"implementation-defined", etc.

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

     [ http://tools.oasis-open.org/issues/browse/OFFICE-3442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Robert Weir  updated OFFICE-3442:
---------------------------------

       Proposal: 
We should put these definitions in a suitable location, perhaps in "Part 0" since they apply to all three parts.  Maybe 1.2 Terminology?  

- implementation-defined behavior:

behavior that depends on the implementation and that each implementation shall document.

- implementation-dependent behavior:

behavior that depends on the implementation.  The implementation is not required  to  document which behavior occurs.  [Note: usually, the range of possible behaviors is delineated by the Standard.]

- undefined behavior:  

behavior for  which  the  Standard imposes no requirements.  Undefined behavior may also be expected when the standard omits the  description of any explicit definition of behavior.


-----------
We should also search all 4 specification documents for synonyms of the above and replace them with one of these three terms, e.g.,

application-defined -> implementation-defined
application-dependent -> implementation-dependent
"not specified" -> application-dependent
unspecified ->application-dependent
"not defined" -> undefined


    Description: 
We need to be clear in our use of terms the allow "dimensions of variability" in implementations.

Previous standards, e.g., C or C++ programming languages,  have made use of three levels:

1) implementation-defined behaviors (sometimes called application-defined).  In this case the standard is allowing the implementation to chose the details of how a feature behaves. It might constrain it to a list of fixed choices ("is implementation-defined but shall be one of X, Y or Z") or it might be open-ended.  The main requirement is that the implementation's choice must be documented ("defined") by the implementation.  So saying something is "implementation-defined" is giving a documentation requirement on the application.  Also, some standards (like C/C++) disallow extreme actions, like failing to compile or crashing.  For example, in C/C++, sizeof(int) is implementation-defined.  But that doesn't mean a C compiler can flag this statement as an error.

2) implementation-dependant (sometimes called unspecified).  This is like implementation-defined but without the documentation requirement.

3) undefined.  This is like implementation-dependent, but extreme behaviors are allowed.  For example, dereferencing a null pointer is undefined C/C++.  Why not just define this to be an error?  It could be done.  Java does that, for example.  But generally undefined is used when the implementation cost or runtime cost of detecting the use undefined behaviors is unacceptable.

Some standards also have a concept of "locale-dependent" behaviors, which is really just a species of implementation-dependent.
I would recommend for ODF, that we adopt these definitions adapted from those used in ISO C++.


  was:
This applies to all three parts really, but maybe we can centralize the definitions in Part 0.  Or would we prefer to restate the definitions (identically) in each part?  Ir invoke them by saying "The terms 'implementation-defined', etc. are used according to their definitions in Part 0, section XXX".

Terms that I know are used include:

Implementation-defined
Implementation-dependent
Undefined
Implementation-specific

Any others?

Suggest we look at the definitions in Part 2 and adopt them if possible. 


> Need to define "implementation-defined", etc.
> ---------------------------------------------
>
>                 Key: OFFICE-3442
>                 URL: http://tools.oasis-open.org/issues/browse/OFFICE-3442
>             Project: OASIS Open Document Format for Office Applications (OpenDocument) TC
>          Issue Type: Bug
>          Components: Conformance
>    Affects Versions: ODF 1.2 CD 05
>            Reporter: Robert Weir 
>            Assignee: Robert Weir 
>             Fix For: ODF 1.2 CD 06
>
>
> We need to be clear in our use of terms the allow "dimensions of variability" in implementations.
> Previous standards, e.g., C or C++ programming languages,  have made use of three levels:
> 1) implementation-defined behaviors (sometimes called application-defined).  In this case the standard is allowing the implementation to chose the details of how a feature behaves. It might constrain it to a list of fixed choices ("is implementation-defined but shall be one of X, Y or Z") or it might be open-ended.  The main requirement is that the implementation's choice must be documented ("defined") by the implementation.  So saying something is "implementation-defined" is giving a documentation requirement on the application.  Also, some standards (like C/C++) disallow extreme actions, like failing to compile or crashing.  For example, in C/C++, sizeof(int) is implementation-defined.  But that doesn't mean a C compiler can flag this statement as an error.
> 2) implementation-dependant (sometimes called unspecified).  This is like implementation-defined but without the documentation requirement.
> 3) undefined.  This is like implementation-dependent, but extreme behaviors are allowed.  For example, dereferencing a null pointer is undefined C/C++.  Why not just define this to be an error?  It could be done.  Java does that, for example.  But generally undefined is used when the implementation cost or runtime cost of detecting the use undefined behaviors is unacceptable.
> Some standards also have a concept of "locale-dependent" behaviors, which is really just a species of implementation-dependent.
> I would recommend for ODF, that we adopt these definitions adapted from those used in ISO C++.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira