Re: [office-formula] Constraints and infix ^

[Patrick Durusau <patrick@durusau.net>]

Rob,

robert_weir@us.ibm.com wrote:
> "Implementation-defined" is not a term that we will see defined in ISO 
> drafting guidelines.  We'll need to explicitly define it in our text what 
> it means.  Certainly in other standards, like ISO C++ items that are 
> implementation-defined can also have additional restrictions specified in 
> the standard. 
>
> It is perfectly legitimate to say "implementation defined" and also 
> specify additional restrictions.  For example, ISO C++ says that the 
> length of a character is implementation-defined, but it must be at least 
> 8-bits long.
>
>   
Err, but doesn't that run afoul of your concerns for interoperability? 
That is in the ISO C++ example there is a floor for representing 
character of 8-bits but what happens if file was generated with an 
application that supported a 16-bit definition is passed to an 
application that only supports 8-bits?

Besides, if the formula group wants a defined set of results, then the 
results aren't by any means "implementation defined," we are simply 
offering a choice to implementations. They cannot chose, for example, 
the weather report that David suggested.

Yes?

Hope you are having a great day!

Patrick
> -Rob
>
>
>
> From:
> "David A. Wheeler" <dwheeler@dwheeler.com>
> To:
> Patrick Durusau <patrick@durusau.net>
> Cc:
> robert_weir@us.ibm.com, office-formula@lists.oasis-open.org
> Date:
> 01/20/2009 10:06 PM
> Subject:
> Re: [office-formula] Constraints and infix ^
>
>
>
> Patrick Durusau wrote:
>   
>> Err, if we say "implementation defined" isn't there a full stop at the 
>> end of that sentence?
>>     
>
> No.  Why would that be so?
>
>   
>> Otherwise, we are contradicting ourselves by then proceeding to define 
>>     
> it.
>   
>> Yes?
>>     
>
> No, I don't think so.
>
> "Implementation-defined" means that the implementation is free to
> pick from a set of possibilities, as long as that selection meets the 
> other requirements of the spec.  If the spec limits the set of 
> permissible returns, then it must be one of those possible returns.
>
>   
>> I really think Rob has the better position to just say "implementation 
>> defined" and then to let it alone.
>>     
>
> That may very well be true!  In which case, let's argue about whether 
> it's better to say "implementation defined, anything at all allowed" or 
> "implementation defined, but must be one of the following {list here}".
>
> Where _possible_, I believe we should try to gain agreement on semantics 
> to the extent we can.  Particularly for such a basic operator as "^". 
> In the case of 0^0, I think there are only 3 plausible responses: 1, an 
> Error, or 0.  I think we can agree that "" is NOT acceptable, yet if we 
> leave it "implementation-defined" without further limitation, then "" is 
> a permissible result.
>
> There are many reasons to try to _limit_ the amount variation in an 
> "implementation-defined" result, if we can.  For example, it's much 
> easier to create portable spreadsheets if we know that only one of a few 
> possibilities can occur.  If 0^0 could produce a text value containing a 
> weather forecast, it'll be harder to create portable spreadsheets :-).
>
> --- David A. Wheeler
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
>
>
>   

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