OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office-formula message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [office-formula] Portable document?


David,

David A. Wheeler wrote:
> Patrick Durusau <patrick@durusau.net> wrote on 01/05/2009 11:57:55 AM:
>   
>>> I find the notion of a "portable" document both interesting and 
>>>       
>> troubling.
>>     
>>> My first impression was that any formula that conforms to OpenFormula 
>>> would be "portable" but then it appeared that I could have a formula 
>>> that conforms to OpenFormula but that isn't "portable." Yes?
>>>       
>
> The issue is that there you can apply the OpenFormula specification to two different kinds of objects:
> 1. applications/implementations: Programs that read data in OpenFormula format, and perform calculations using them.
> 2. documents/data files: Data in OpenFormula format.
>
> For case #1, you want an implementation to implement the specification.  If it does other things, in addition, that's fine... as long as it meets the spec.
>
> But for case #2, a document might very well need a function that is NOT in OpenFormula.  In that case, we want the document to use the specification as much as it can, and then only add what's needed.  In fact, we have a naming scheme for new functions, to make that easier to do.  But then... how can we separate documents that ONLY use what's specified in OpenFormula, vs. those that use OpenFormula but add functions (or require additional size limits, etc.)?
>
>   
Err, but OpenDocument faces the same issue, hence the allowance for 
foreign elements and attributes.

The only guaranteed result or "portability" is for documents that only 
use elements/attributes defined by OpenDocument.

Hence, applications "should" preserve foreign elements/attributes. In 
case the document makes it to an application that understands the 
material not defined by OpenDocument.

That is conformance but only to the extent OpenDocument has in fact 
defined the syntax/semantics.
> The proposed answer is the term "portable document" - one that ONLY uses the capabilities specified.  That way, you can add specialized functions, while still maximally using what's specified.  OpenFormula has requirements on how to name functions not defined in the spec, so this is not a vacuous requirement.  And since it gives us a way to grow, it's a useful one too.
>
>   
I didn't mean to suggest that it was "a vacuous requirement" but was 
concerned about what it meant, beyond simply conforming to what has been 
specified.

If I am reading your answer correctly, then to conform to OpenFormula 
*means* that you have a "portable" document. That is assuming that we 
express all the "basic" limits as limitations on the format that is 
being defined.

>>> I suppose it is a matter of perspective.
>>>       
>
> Yes.
>
>   
>>> I see conformance to the 
>>> standard as the "test" for portability. By analogy, it would be similar 
>>> to having the "small group" but with value limits as part of its 
>>> semantics. If I conform to the "small group" with those semantics, then 
>>> my document will travel safely to any other application that supports 
>>> the "small group" set of functions. Or be, at least to my way of 
>>> thinking, "portable."
>>>       
>
> Yes.   The challenge is, what do we do about documents that include functions that are NOT specified anywhere, but otherwise conform to the spec?  Thus the distinction.
>
>   
Hmmm, do you mean that with the exception of a function that is not 
specified by OpenFormula the document otherwise conforms to OpenDocument 
and perhaps has other formulas, etc., as specified by OpenFormula?

Why isn't that the case you mentioned above of providing a namespace for 
a function not defined by OpenFormula?

Perhaps I don't understand your question.

I would say that the document does conform to the 
OpenDocument/OpenFormula standards. After all, OpenFormula *says* that 
it can have such new functions, provided it is in another namespace 
other than OpenFormula (I would assume that is your intent).
>>> PS: Before I forget, is there a reason why we don't cite the W3C 
>>> definitions of values types in chapter 4? Granted that some of our 
>>> definitions are different but not all of them. Yes?
>>>       
>
> I don't remember there being any particular reason.
> Which spec do you mean by "the" W3C definitions?  The XML spec?
>
>   
The W3C XSD datatypes.
> robert_weir:
>   
>> I see 'portable document' as a conformance class, but of the document, not 
>> the application.
>>     
>
> Yes.
>
>   
>> ... We could certainly argue whether the portable conformance belongs in the 
>> core ODF 1.2 OpenFormula, or whether we want to defer this to a later 
>> "ODF/A" profile.
>>     
>
> I think this is important enough to include in the base document.
>
>   
I agree it is important but I suspect we are using different models or 
terminology for conformance.

I think we all want a document that conforms to OpenDocument/OpenFormula 
to be interchangeable, the question seems to be if we call that 
"portable" for conformance to OpenFormula (subject to David and others 
curing my mis-impressions on this issue.)
>> Another approach, perhaps complementary, would be to mandate a set of 
>> "capabilities" functions whereby an implementation would report its 
>> maximum string size, its maximum integer size, what group of functions it 
>> supports, etc.  C/C++ has uses a similar approach.  It is easy for a user 
>> to create a portable document if they have functions such as 
>> maxStringLength(), etc., to conditionalize their formula logic or to 
>> report errors.
>>     
>
> The problem is that many spreadsheet users aren't as sophisticated as most C/C++ users.
> Programming effectively in C or C++ requires that you be able to understand
> and correctly concepts such as pointers and memory allocation.  In short,
> C and C++ are intended for use by people who are already computing experts.
>
>   
I think Rob's point was what I was attempting to say in part of my 
original post. That is that limits can be defined in the semantics of 
OpenFormula.

For example, you can say that a string is a set of characters of length 
no greater than 32,767 characters (assuming elsewhere you reference or 
define characters). And that is the test for all strings that "conform" 
to OpenFormula. You can certainly have a string that is longer than that 
but you are now beyond what has been defined by the standard.

Ah, is that the issue? That you want to have a "soft" limit on 
conformance so that an application that supports strings greater than 
32,767 characters in length still conforms to OpenFormula?

That is we are not talking about something that OpenFormula doesn't 
define, we are talking about supporting value ranges that OpenFormula 
*does define* but only part of any value range is likely to be commonly 
supported.

If that is the issue, here is one way to do that and still make it a 
format limitation (not a limit on implementations):

1. Define the various groups for conformance

2. Define limits in whatever grouping seem appropriate. For example 
there could be one group that has all the basic limits and another where 
strings for example can be longer than 32,767 characters, functions can 
have more than 30 parameters, etc.

3. Define levels of conformance such as small group + basic limits, 
small group + no limits, etc.

Closer? Farer away?

Hope you are having a great day!

Patrick

-- 
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)



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]