OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

office-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: ODFF: a practical issue

ODFF 15Nov07 version:

I have a concern about the practicality of producing a 'portable 
document' with ODFF. Using an example (one of many):

The DAYS() function requires two DateParam parameters.

I believe it is the intention that DateParam should produce or be 
an integer Number - although to me this reads as an inference 
rather than a requirement (see 4.8.2 DateParam, 4.2.2 Date and 
DateTime - does this need tightening up?).

Assuming that DateParam *is* to yield an integer Number, the 
specification for DAYS() does not set out what is to happen if a 
non-integer is presented. For example DAYS("25Dec07";NOW()).

This is an easy mistake for a user to make - indeed whoever 
compiled the current Calc Help documentation made it. It should 
be DAYS("25Dec07";TODAY()) of course. But as it stands it gives a 
valid ODFF document, but not a *portable* ODFF document, as each 
app is free to implement this differently. [Calc for instance 
returns a fraction; other apps might use INT()]

ODFF deals with this as follows:

"2. Conformance

....Applications should clearly document their extensions in 
their user documentation, both online and paper, in a manner so 
users would be likely to be aware when they are using a non-
standard extension.


... A portable document shall only depend on the capabilities 
defined in this specification, and shall not depend on undefined 
or implementation-defined behavior."

It seems to me that
a) Making the documentation clear increases its size 
considerably, and decreases its readability - if it is to alert 
the user to this type of non-conformance. This is probably a 
price that must be paid.
b) Even so, very few users will consult the documentation every 
time they use a function.
c) Fewer users still will realise their mistake.

The practical result is that unless ODFF *requires* applications 
to check conformance strictly there will be two types of ODFF 
documents in circulation - 'portable' and 'non-portable'. And 
ODFF does not have a mechanism to distinguish between them.

This seems to me to be a rather serious limitation. Delighted to 
be corrected if I am wrong...

My solution, for what it is worth, would be to have a element in 
the document which states if it is portable - set by those apps 
which check conformance strictly.

David King

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]