Re: [office-formula] On "portability"

[Patrick Durusau <patrick@durusau.net>]

Michael,

OK, that helps.

So in one view, the "portable" document comments are simply helpful 
observations for implementers/users and don't have an impact on the 
conformance clauses.

Such observations could be gathered up in a non-normative annex. That 
would simplify the text in a number of cases.

I don't think that answers the observation certain assumptions have to 
be made about an environment by definitions in OpenFormula.

Hope you are having a great day!

Patrick

PS: The reason I was suggesting that "portable" be the standard is that 
I consider one of the purposes of standards is to make 
documents/formulas interchangeable. Allowing extension as well as 
various ways to conform diminish the ability to achieve that goal. All 
standards do allow both extension as well as different ways to conform 
but the question is where to draw the line.

Michael Brauer - Sun Germany - ham02 - Hamburg wrote:
> 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
>>>
>>>
>>>
>>
>
>

-- 
Patrick Durusau
patrick@durusau.net
Chair, V1 - US TAG to JTC 1/SC 34
Convener, JTC 1/SC 34/WG 3 (Topic Maps)
Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)