Re: [office-formula] Portable "documents"

[Patrick Durusau <patrick@durusau.net>]

Michael,

Michael Brauer - Sun Germany - ham02 - Hamburg wrote:
> Rob, Patrick, all,
>
> a few more comments are below, but my impression is that the portable
> document issue can only be solved by looking at the various places where
> the term "portable" is used individually. So, what about the following
> approach:
>
> 1. In a first pass the specification is adapted to make use of the new
> performance targets the SC has agreed. Essentially this means that terms
> like "document" are replaced with "expressions" and terms like
> "implementation" and "program" are replaced with "evaluator". This may 
> require small adaptations of the language (in particular if must is 
> replaced by shall, etc. at the same time), but should not change the 
> constrains themselves.
>
OK.
> 2. In a 2nd pass, or in parallel, the portable document statements are
> turned into notes, but without rephrasing them or moving them.
>
A bit more difficult as some of the portable statements are mixed in 
with other content. But I understand the request.
> 3. In a third pass, the notes are checked individually. If they can be
> turned into statements what is implementation or undefined behavior of
> evaluators, they are rephrased accordingly. If they can be turned into
> statements what is optional behavior of an evaluator, the are also
> rephrased accordingly. And if both is not possible, they are kept as is.
>
Err, so if it is possible to re-phrase a "portable document" statement 
as would be the case for minimum integer size (I like that example by 
the way) that would no longer be a note but a normative requirement:

evaluators shall support integers up to (some size). Evaluators may 
support integers in excess of (some size).

Making conformance a matter of supporting the minimal amount. Supporting 
the larger amount is also conformance because it includes the lesser 
amount.

The question then becomes what do we require, if anything, of 
applications that support larger amounts? Are those implementation 
dependent or defined?
>
> Some more comments are inline.
>
>
> On 12/15/09 22:38, robert_weir@us.ibm.com wrote:
>> Patrick Durusau <patrick@durusau.net> wrote on 12/15/2009 08:59:27 AM:
>>
>> For example, instead of saying "Portable programs shall not 
>> dereference a null pointer", we would say "The value of a 
>> dereferenced null pointer is undefined".  Or instead of saying "A 
>> portable program shall not depend on the size of an integer" we would 
>> say "The size of an integer is implementation-defined".  So, the 
>> concept of a portable program was not explicitly stated, although in 
>> practice it could be derived:
>>
>> 1) Avoid all undefined behaviors
>> 2) Do not depend on any implementation-defined or 
>> implementation-dependent behaviors
>
> I think it is important that we always state here if we are talking
> about expressions or evaluators. The size of an integer is actually a
> property of an evaluator, and dereferencing the a pointer is an
> operation of an evaluator. So, what we are talking about here are
> behaviors of evaluators.
>
> In contrast, we talk about expression if we say undefined and 
> implementation defined behavior should be avoided. If one does so, on 
> gets a portable document.  So, what we may say is that there is a set 
> of implementation defined, undefined and optional behaviors for 
> evaluators, and that one gets portable expressions by not relying on 
> these behaviors.
>
OK.
>>
>> I wonder if an approach like that might result in a tighter 
>> specification?  In other words, rephrase all portability constraints 
>> as positive statements about undefined, implementation-defined and 
>> implementation-dependent behaviors?
>
> This goes into the same direction as I have suggested a few days ago.
> So, yes, this may be a reasonable approach, except that I think there
> are more options to rephrase statements about portable document than
> turning them into statements what is undefined, implementation defined
> or implementation dependent. Another option is to declare behavior to be
> optional. For instance, while the size of an integer is undefined, there
> may be a minimum size that all evaluators shall support. But evaluators
> may support larger integer values. If they do so, the result is well
> defined. Only only does not know whether larger values are supported.
>
> So, if we say that the size of an integer value us undefined, there is 
> no information what integer size is supported by all applications.
>
> If we specify the minimum integer size, and declare the use of larger 
> integer sizes to be optional, document authors know the minimum 
> integer size that is supported, and they also know that if larger 
> sizes are supported, the result of the formulas is well-defined. 
> That's much more than in the first case.
>
As I said above, I like this example.

Perhaps it will be easier to reach a consensus or at least move in that 
direction with the first couple of steps that you suggest above. Some of 
the "portability" issues are likely to attract near universal consent, 
like integer size. It may help us move more quickly than debating 
"portability" in abstract.

Unless Eike needs the text back to enter more of his technical 
corrections, I will start working on it along these lines. Will try to 
upload a rough version by next Monday so everyone can see the 
preliminary results.

Hope you are having a great week!

Patrick

-- 
Patrick Durusau
patrick@durusau.net
Chair, V1 - US TAG to JTC 1/SC 34
Convener, JTC 1/SC 34/WG 3 (Topic Maps)
Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)