[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office-formula] Portable "documents"
Patrick Durusau <firstname.lastname@example.org> wrote on 12/15/2009 08:59:27 AM: > > My major concern at present is what to do with the notion of "portable > documents." > > First, understand that my role is really to help the formula SC and the > ODF TC to say what they want to say. I may or may not agree and will > argue for my position but ultimately, my task is one of expressing the > committee's view in standards prose. So we start with two conformance targets: formulas and formula processors. Part 2 defines requirements and recommendations (shall's and should's) for these two conformance targets. There are then a set of additional requirements and recommendations that pertain to "portable documents". So on the face, this sounds like a conformance class. Certainly there are exceptions, where the portable document constraint is constraining user behavior, but for the most part these seem like coherent requirements, or can easily be rewritten to be so. In any case, we have a range of ways to treat this: 1) Have two expression conformance classes: formula and portable formula. Remove any portability constraint that is not a testable assertion about the static properties of a formula string. Watch out especially for the ones that say "Portable documents shall not depend on X". This appears to be different than just "Portable documents shall not use/contain X". I think these are saying (essentially) that the results of the formula should not be able to determine whether or not X exists, or that the results of the formula shall not differ based on the presence or absence of X". I understand the concept, but find it hard to express in testable terms. 2) Have a single conformance class, and turn all portability constraints into conformance requirements (again removing those that are not statically testable). So all conforming formulas must adhere to these requirements. 3) Keep conformance as it is and move all portable document statements to an informative annex or to a separate document (not part of ODF 1.2). My preference would be for #2. I don't want to make more work for implementations than necessary, but I think that achieving some level of portability should be a necessary goal of this work. So if portability requires a given constraint, then why wouldn't we make it a requirement? The reality is we can define a "common intersection" of spreadsheet functionality that would be widely portable, although no spreadsheet application is likely to constrain users to using only portable constructs. And if we define a broader subset of functionality in OpenFormula then it will allow some formulas that will not be portable. This is a common situation with other standards, especially computer language standards. In those cases, it was common to define the opposite of portability constraints. 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 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? -Rob