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] One strictly conforming document?


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


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