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 "documents"


Andreas,

OK, so why would a *standard* be giving non-normative advice to authors?

Note material I suppose in ISO parlance but an awful lot of it.

That doable, in terms of having an annex for big chunks of "advice" to 
authors and then making the "portable" comments as notes under the 
various functions.

But, I keep getting the sense from some of the language and members of 
the formula group, that there is a sense in which a "portable document" 
conforms to some set of specified conditions. Yes? (Realizing you may 
not agree with that position but it doesn't mean that it doesn't exist. 
Perhaps it should not be the position of the formula group or the ODF 
TC, but that is a separate question.)

If that set of conditions is "normative," that changes how we need to 
treat those conditions in the draft.

Hope you are having a great day!

Patrick

Andreas J. Guelzow wrote:
> On Tue, 2009-12-15 at 21:24 -0500, Patrick Durusau wrote:
>   
>> I have been out most of the day but I wanted to reply to at least one 
>> formula post before closing down for the night.
>>
>> Eike Rathke wrote:
>>     
>>> Correct. A portable document and the portable constraints mentioned for
>>> functions are document author guidelines, not implementor conformance
>>> clauses. The portable term reduces a feature or function to a common
>>> denominator implemented by existing applications. New implementations
>>> should strive for more that usually is expressed as 'should'. If
>>> a document is not restricted to portable constraints it does not mean
>>> that the document is not conforming.
>>>
>>>   
>>>       
>> OK, say I have an evaluator that conforms to the "small" group of functions.
>>
>> How does that differ from an evaluator that conforms to the "small" 
>> group of functions *and* only supports portable documents?
>>     
>
> That is simply not possible. An evaluator that conforms to the "small"
> group of functions cannot only support portable documents:
>
> Take the DATE function. To conform the evaluator must be able to
> construct a date from year, month, and day of month for any integer
> year, integer month and integer day. There are no constraints for those
> items. On the other hand DATE has portable constraints. So there are
> non-portable documents that any evaluator conforming to the "small"
> group of functions must support.
>
>   
>>  From a conformance standpoint?
>>
>> In other words, it sounds like the "portable" constraints are creating a 
>> subset of a larger set requirements, to which an evaluator could conform.
>>
>> Is there some reason to not say:
>>
>> Level 1 - conforms to small group and only up to portable constraints
>>     
>
> impossible
>
>   
>> Level 2 - conforms to small group and beyond X portable constraints
>>     
>
> the second part follows from the first for some X>0
>
>   
>> Level 3 - conforms to medium group and only to portable constraints
>>     
>
> impossible
>
>   
>> etc. ?
>>
>> It seems me, and I may be wrong, that the current draft wants to state a 
>> rule but then doesn't, or at least doesn't want it to be a hard rule.
>>     
>
> The portable constraints are just guidelines for users...
>   
>
> Andreas
>
>   

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