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

 


Help: OASIS Mailing Lists Help | MarkMail Help

office message

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


Subject: Re: [office] Suggestion from the ISO meeting in Seattle


Rob,

robert_weir@us.ibm.com wrote:
> Patrick,
>
> I don't think we can mark something as "implementation-defined" in 
> Approved Errata, since that would be adding a new requirement (a 
> requirement for the implementation to specify its behavior) on existing 
> implementations, something we are not permitted to do under OASIS rules. 
>
> However, "implementation-dependent" would be fine. 
>
> Of course, in ODF 1.2 we are free to say "implementation-defined" if we 
> want.
>
>   
Good point!

I was thinking more of a good future practice as I am sure there are 
going to be things we are better off to simply require applications to 
define what they do, rather than our trying to wade into the weeds to 
sort some problems out.

Hope you are having a great day!

Patrick
> -Rob
>
>
> Patrick Durusau <patrick@durusau.net> wrote on 09/24/2009 07:49:17 AM:
>
>
>   
>> Greetings!
>>
>> During the ISO discussions in Seattle last week the following suggestion 
>>     
>
>   
>> was made for cases where the standard does not or cannot define precise 
>> behavior.
>>
>>     
>>> From ISO 9075-1:2008 SQL/Framework:
>>>
>>> * *
>>>
>>> *7.2 Implementation-defined elements*
>>>
>>> Every part of ISO/IEC 9075 contains an Annex that lists every element 
>>> of SQL and its processing that is specified
>>>
>>> in that part, and is permitted to differ between SQL-implementations, 
>>> but is required to be specified by
>>>
>>> the implementor for each particular SQL-implementation.
>>>
>>> * *
>>>
>>> *7.3 Implementation-dependent elements*
>>>
>>> Every part of ISO/IEC 9075 contains an Annex that lists every element 
>>> of SQL and its processing that is mentioned,
>>>
>>> but not specified in that part, and is thus permitted to differ 
>>> between SQL-implementations, but is not
>>>
>>> required to be specified by the implementor for any particular 
>>> SQL-implementation.
>>>       
>> This came up in the context of discussions about corrections to ISO 
>> 26300. Particularly areas where in retrospect we were not completely 
>> precise and to offer more precision now might create incompatibilities 
>> with existing implementations.
>>
>> I think it is an interesting suggestion and one that could prove to be 
>> useful.
>>
>> Hope everyone is having a great week!
>>
>> 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)
>>
>>
>> ---------------------------------------------------------------------
>> 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)



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