[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office] One strictly conforming document?
Patrick Durusau <patrick@durusau.net> wrote on 02/03/2009 09:15:01 AM: > 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. > I'd agree that the average, off the street, solitary user is on their own when evaluating an application's conformance. But government procurement has a bit more power. They can and typically do require a Supplier's Declaration of Conformity, signed by the supplier, for any sold product, according to ISO Guide 22. So exactly how conformance is defined is not something we can merely brush off as having no value. > 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. > Agreed. But will you agree that a document which is extended with a schema not defined by the standard can be far less interoperable than one which sticks to the standardized schema? > 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. > This is really a red herring. However bad you think interoperability would be in that case, you must admit that it is made worse, not better, by extending the documents with private schemas. Also consider that the problem you describe above can be addressed and is being addressed by interoperability testing, the work of the OIC TC, etc. The ODF vendors, most of them at least, have a keen interest in improving interoperability in that area. However, allow ODF documents to be freely extended with private schemas without the user's choice, and you have made the problem much much harder. We can improve interoperability where we agree on a schema. But it is considerable more difficult to do that when a private schema is involved, one which perhaps is not disclosed. Remember a private schema extension is not even required to be made available on RAND terms, let alone made freely available. > 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 ableto 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) > > > --------------------------------------------------------------------- > 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 >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]