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