Portable Notes

[Michael Brauer - Sun Germany - ham02 - Hamburg <Michael.Brauer@Sun.COM>]

Hi,

one of the outstanding issues of the formula specification seems to be
the portable notes. Patrick has already marked them, but is seems to be
an open question what should happen to them next.

It seems to me that most if not all portable notes are in one of these 
categories

1) Portable Notes/Constrains that list values that are supported by all 
known implementations. An example for these are the portable constrains 
in 5.4.6:

 > Portable Constraints: NOT(AND(Left=0; Right=0))

5.6.2:

 > Portable Constraints: INT(X)=X, INT(Y)=Y

and the following sentence from 3.3:

 > Portable documents shall
 > not assume that negative date values are impossible (many
 > implementations use negative dates to represent dates before the epoch).

My suggestion is that we turn these notes into normative statements that 
declare the support of the values listed as portable constrains to be 
mandatory. Other values that are not part of the current portable 
constrains when would become optional.

2) Portable Notes/Constrains that provide hints where behavior is 
implementation dependent and that possibly provide recommendations how 
to avoid that behavior in expressions. Examples for this are in 3.3:

 > Portable spreadsheet files shall not assume any particular epoch
 > values.

and

 > Portable documents shall not include date calculations that require
 > the incorrect assumption that 1900 was a leap year. [...]
 > Portable documents should use the epoch date 1899-12-30 to compensate
 > for serial numbers originating from applications that include a
 > 1900-02-29 leap day in their calculations.

I suggest that the turn these kind of portable notes into 
recommendations to expression authors or implementors.



To provide a few examples:

1) The first portability note in 3.3 is

"Portable spreadsheet files shall not assume any particular epoch "values.

This is actually a hint that expressions that make assumption about the 
epoch date may be non portable or non interoperable. It could be turned 
into:

"Note: Using expressions that assume that serial numbers are based on a
particular epoch may cause interoperability issues".

or:

"Note: Expression authors should consider that the epoch date may vary
between implementations. Expressions that assume a particular epoch
date may have different results depending on the implementation".

2) The 2nd note in 3.3, that now is

"Portable documents shall not include date calculations that require the
incorrect assumption that 1900 was a leap year. Portable documents shall
not assume that negative date values are impossible (many
implementations use negative dates to represent dates before the epoch).
  Portable documents should use the epoch date 1899-12-30 to compensate
for serial numbers originating from applications that include a
1900-02-29 leap day in their calculations. "

could become:

"Conforming evaluators shall support positive serial numbers. They may
support negative serial numbers to represent dates before the epoch.

Note: Expression authors should consider that it is implementation
specific whether 1900 is considered to be a leap year.

Note: It is recommended that implementations that consider 1900 to be a
non leap year use the epoch date 1899-12-30 to compensate
for serial numbers originating from implementations that consider 1900
to be a leap year and use the 1899-12-31 epoch date."

The first sentence has been turned into a note to expression authors 
that they must not make any assumptions whether 1900 is considered to a 
leap year. The 2nd sentence has been turned into a normative statement 
that positive serial numbers shall be supported. They are already 
supported by existing implementations. And new implementation shall 
support them probably as well. The support of negative serial numbers is 
optional. By making them optional it gets clear that they may be used, 
but at the same time expression authors are warned that they may not be 
supported by all applications.

The third sentence has been turned into a recommendation to implementors.


3) For the notes in 5.4.6 and 5.6.2 we could turn the "portable 
constrains" into "constrains". For the case where we do that (and only 
there) we must turn the existing constrain into optionally supported values.

5.4.6, that now reads,

Constraints: OR(Left != 0; Right != 0)
Portable Constraints: NOT(AND(Left=0; Right=0))

may become:

Constraints: NOT(AND(Left=0; Right=0)); Evaluators may also evaluate
expressions where OR(Left != 0; Right != 0) to a non-error value.

5.6.2, that now reads:

Constraints: None
Portable Constraints: INT(X)=X, INT(Y)=Y

may become:

Constraints: INT(X)=X, INT(Y)=Y; Evaluators may also evaluate
expressions that do not meet this constrain to a non-error value.


The general rule (for portable constrains) is:

If a function has "constrains" and "portable constrains", then the
portable constrains become "constrains", and the former constrains
become optional values.

If a function has "constrains" only, then these constrains remain
mandatory constrains.

The idea here is that values that are portable are implemented by all 
existing implementations, and shall be implemented by all future 
implementations to get portable. It is therefore reasonable to make them 
a "shall". Other values that meet the "constrains" but not the "portable 
constrains" are not supported by all applications. That's why they got a 
"may".

Best regards

Michael


-- 
Michael Brauer, Technical Architect Software Engineering
StarOffice/OpenOffice.org
Sun Microsystems GmbH             Nagelsweg 55
D-20097 Hamburg, Germany          michael.brauer@sun.com
http://sun.com/staroffice         +49 40 23646 500
http://blogs.sun.com/GullFOSS

Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1,
	   D-85551 Kirchheim-Heimstetten
Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: Thomas Schroeder