Subject: Re: [office-formula] On "portability"
Hi Patrick, Am 09.12.09 11:24, Patrick Durusau schrieb: > Michael, > > Comments below: > >> "Portable documents should limit the names of their identifiers to >> only (Unicode) letters, underscores, and digits, not including >> patterns that look like cell references or the words True or False." >> >> This could be read as: "Evaluators shall support identifiers that >> consist of (Unicode) letters, underscores, and digits unless the >> identifier matches the syntax of a cell reference, or contains the >> terms "True" or "False". >> > Err, on that last point, wasn't the intent of the original text to > exclude "patterns that look like cell references or the words True or > False?" > > That is to say that identifiers should not "look like" (I can hear the > UK comment even as I say that) cell references or be the words True or > False? > > Which I would re-word to read: > > Identifiers shall consist of Unicode (do you want character classes > here?, underscore is only one character) characters and shall not match > the syntax of a cell reference and shall not be the words True or False. In this case, we may also specify this as a requirement for documents, but it must be a "should" rather than a "shall". Otherwise we exclude documents that contain other identifiers, and this is I think not the intention. > > True that people can choose to use other identifiers but then they are > not conforming to OpenFormula. > > **** > > Back to main issue: > > To no small degree, I think OpenFormula needs to be less descriptive and > more prescriptive, what it nows calls "portable." Yes, there will be > behaviors beyond that which we define but that will always be true. If a > user goes beyond the standard, say they have identifiers written in some > dialect of InterGalactic, they aren't going to have much success sharing > their spreadsheets. But it will also be the case that they did not > conform to OpenFormula so they were on notice that would be the case. Well, what we have at the moment are "conforming documents/expressions" and "conforming implementations/evaluators". And we have a class of documents that are called portable. These are a subset of conforming documents. I think what we are not discussing is that only portable documents are conforming documents in the future. What we are discussing is whether "portable documents" are a conformance class of its own, whether there shall be a set of guidelines to authors, or whether they shall be removed. If they would be removed, my understanding is that they would be removed by just removing them, but not by turning what is now a portable document into the the only kind of conforming document. That means, whatever we do with portable documents and constrains, it does not change the current definition of a conforming document/expression or conforming implementation/evaluator. Because documents get portable if they use only features and values that are supported by all evaluators, and because function parameters etc. can only be checked at evaluation time, my suggestion was that we instead of defining portable documents define the minimums set of functions and parameter ranges etc. that an evaluator supports. But that's just one of many option. Like any other option we have this of cause requires to adapt at least some of the definitions where we say something is portable. But before we can adapt these definitions, we need to know what the concept of "portable" should be. > > Standards, for good or ill, are supposed to be prescriptive of a limited > range of behaviors. That doesn't mean that there are not behaviors > beyond what the standard describes, there always are, but those are not > the concern of the standard. Yes, but there could also be behavior that is implementation defined or optional. I think it is valid to say that an evaluator shall support a certain value range, but may support values outside the value range. An expression that uses values outside the value range may anyway be conforming, but there may be applications that do not support them. Let me give another example: We do not have any restrictions of page size in part 1, but we could in a future version add that a consumer must at least support pages sizes up to DIN A3. If an author then creates a document with an A2 page size, the document probably shall remain a valid ODF document. But it may not be supported by all applications. I hope this clarifies my suggestion. Best regards Michael > > I like your idea of saying that OpenFormula provides definite results > only under a defined set of conditions. I think that will give us the > ability to make explicit assumptions about the operating environment and > reduce the number of asides and exceptions. > > Hope you are having a great day! > > Patrick > >> Best regards >> >> Michael >> >> >> > -- Michael Brauer, Technical Architect Software Engineering StarOffice/OpenOffice.org Sun Microsystems GmbH Nagelsweg 55 D-20097 Hamburg, Germany firstname.lastname@example.org 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, Wolfgang Engels, Wolf Frenkel Vorsitzender des Aufsichtsrates: Martin Haering