[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]