Re: [office] One strictly conforming document?

[Patrick Durusau <patrick@durusau.net>]

Bob,

You say below:

> My preference would still be very much for the single strict
> conformance class for documents, with no foreign elements except in
> the agreed upon locations.  I will shift extremely reluctantly (wild
> horses ...) towards a mish-mash of conformance permutations.
Well, but the shift is to the "stricter" conformance so the burden of 
establishing that need in on those who desire it.

A conformance clause does not have the talisman like quality that seem 
to be desired to distinguish between applications.

Users will always have the responsibility of evaluating claims of 
conformance. Or to put it another way, conformance clauses are not 
self-executing.

For that matter, users really should be evaluating their *requirements* 
and not conformance clauses of standards.

And as I said in my presentations in South Africa last summer, 
conformance to a standard is a necessary but not sufficient condition 
for interoperability.

If you want that in terms of conformance to ODF 1.2, consider a set of 
strictly conforming ODF documents that use different semantics for their 
content. Sure the documents are "interchangeable" from the standpoint of 
the ODF standard, but if they are being exchanged between a hospital and 
a central health authority, that interchangeability is all but useless 
in the face of differing semantics. Meets the "strict ODF 1.2 
conformance clause" test but not the user requirement for interoperability.

Hope you are having a great day!

Patrick

Bob Jolliffe wrote:
> Greetings,
>
> 2009/2/3 Michael Brauer - Sun Germany - ham02 - Hamburg
> <Michael.Brauer@sun.com>:
>   
>> Hi Patrick,
>>
>> On 02/02/09 15:46, Patrick Durusau wrote:
>>     
>>> Greetings!
>>>
>>> Granted that I fully support Michael's notion that the ODF TC should in
>>> the future be able to more routinely produce standard extensions to the
>>> format, but I also realize there maybe custom uses where there is no desire
>>> or need for an standardized extension. Or at least I would prefer to keep
>>> that open as a possibility and not to deny applications that substantially
>>> rely on ODF 1.2 from being able to claim that they conform to ODF 1.2 (as
>>> does their output, to the extent that it does).
>>>       
>> I think it is important that users know whether an application that claims
>> to be ODF 1.2 compliant is able to store documents without extensions, or
>> only documents that contain such extensions. So, if we would give up the
>> requirement that all ODF producers are able to produce strict conforming
>> documents, we at least would need an additional conformance class for
>> producers, so that one can differ between a producer that is able to create
>> strictly conforming documents, and one that isn't. This may be an option,
>> but it doesn't make it easier to understand what the various conformance
>> levels actually mean.
>>
>> What do you think?
>>     
>
> The Department of Science and Technology, and the South African public
> service as a whole, is a user of ODF 1.1 and we hope soon to become a
> user of ODF 1.2.  For us the benefit of mandating compliance to a
> standard is to clarify procurement processes and to open the field to
> competing vendors around an agreed upon standard.
>
> Anticipating (and encouraging) a heterogeneous mix of application
> software, we would strongly support any moves in the direction of
> stricter conformance requirements and equally discourage any moves
> towards sanctioning loose conformance categories - either for
> conforming documents or for conforming applications.  Put simply, if
> we have deployed three different word-processing applications we
> require that the output of those applications are in strict agreement
> with one another.  I would not agree to dropping the requirement that
> producers are available to produce strictly conforming documents.  If
> a producer is not capable of producing strictly conforming documents
> then it should not be called a conforming producer.  A nearly
> conforming one perhaps.  The option of creating additional conformance
> classes for producers serves no useful purpose for us.  In fact it can
> only make our procurement processes more convoluted and increase the
> risk of procuring systems which are less interoperable than they might
> otherwise be.
>
> One can't help recalling that in 1995 the National Institute of
> Standards and Technology in the US certified NT as complying with the
> Posix standard, Federal Information Processing Standard 151-2 for open
> operating systems.  POSIX compliance in that case was seen simply as a
> hurdle to be cleared in order to make it into the tender stable.
> Similarly we have dozens of hospitals around the country claiming HL7
> compliance, but they cannot exchange data with one another.
>
> If there are "custom uses where there is no desire or need for an
> standardized extension", and I am sure there are many, then I would
> argue that there is equally no need to claim conformance in those
> cases.
>
> My preference would still be very much for the single strict
> conformance class for documents, with no foreign elements except in
> the agreed upon locations.  I will shift extremely reluctantly (wild
> horses ...) towards a mish-mash of conformance permutations.
>
> Regards
> Bob
>
>   
>> Best regards
>>
>> Michael
>>     
>>> Hope everyone is at the start of a great week!
>>>
>>> Patrick
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>       
>> --
>> Michael Brauer, Technical Architect Software Engineering
>> StarOffice/OpenOffice.org
>> Sun Microsystems GmbH             Nagelsweg 55
>> D-20097 Hamburg, Germany          michael.brauer@sun.com
>> http://sun.com/staroffice         +49 40 23646 500
>> http://blogs.sun.com/GullFOSS
>>
>> Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1,
>>           D-85551 Kirchheim-Heimstetten
>> Amtsgericht Muenchen: HRB 161028
>> Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer
>> Vorsitzender des Aufsichtsrates: Martin Haering
>>
>> ---------------------------------------------------------------------
>> 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
>>
>> --
>> This message has been scanned by DST MailScanner
>>
>>
>>
>>     
>
> ---------------------------------------------------------------------
> 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)