[OASIS Issue Tracker] Commented: (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:comment-tabpanel&focusedCommentId=21543#action_21543 ] 

Dennis Hamilton commented on OFFICE-3442:
-----------------------------------------

In the proposal, I would remove the note concerning implementation-dependent behavior.  I am not certain that it is the case, and whatever is the case also applies to implementation-dependent.

Concerning undefined, I don't think think that explicitly specifying something as undefined and having something be undefined by omission should be put on equal footing.   I don't see how absence of a statement constitutes normative language and we should not elevate the omission case.  (Say nothing about that seems better.)

I note there is a flavor of implementation-defined that is not exactly that, although it is externally-defined by reference in the document itself.   I am thinking of the use of namespace bindings to establish definitions of syntax and semantics for certain markup.  Someone may be using that without being the definer of it.   In that case, would it be enough for the producer to declare that such-and-such namespace bindings are used where namespace bindings are allowed, and at most point to the definition elsewhere?  And perhaps we should require this in the places where we allow namespace bindings in this way?  

> 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