[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [office] Conformance Clause proposal, Version 8
Michael, I will examine the revision with great interest. Thanks for your struggling with this. 1. I favor the two-tiered approach, as you know. 2. I am assuming that the only schema will now be what has been called the strict schema in the past. That is an useful simplification. 3. I don't like the names very much, but that may be just me. 3.1 For one thing, I have become fond of "strict conformance" and "strictly-conformant." I find that a powerful designation and I think it aligns with the strong goals of those communities that establish requirements for use of strictly-conformant ODF Documents in interchange and for public and civil purposes. It seems useful in branding, badging, and for other purposes where documents are expected to be squeeky clean. 3.2 For the other, the term is simply too geeky and I don't think it helps maintain a common understanding of what it is about. I guess it means that ODF is the host language for a customized version with limited extensions (foreign elements being a circumscribed way of doing it, especially if the underlying strictly-conformant ODF document is meant to be useful). Is that the sense you give it? 4. I am not objecting to qualifying the term if it is as easy to convey as strict conformance is and we are clear about the correspondence with "conformant" in previous specifications. [In thinking out loud, below, I came up with "conformable" for the document, in contrast with the strictly-conformant document, but producers would still be conforming and strictly conforming, I think.] 5. Maybe we can kick this around for a few days in search of a better term. If strict conformance is as appealing to others as I find it, maybe we just use plain conformance in the sense it has for ODF 1.1 for now, with leaving the search for a better term open. - Dennis - - - - - - - - - - - More thinking out loud - Terms I rejected when thinking about this: - loose conformance (has the right tone, but can apply as easily to a strictly-conforming consumer and producer) - weak conformance (same problem as above) - limited conformance (ditto) - modified conformance (again) - altered conformance (?) - custom conformance (sounds too much like a feature) - extended conformance (likewise) If the words conformant and conformance are not used, or not used alone, so there is no contraction that creates confusion with (strict) conformance and (strictly) conformant, that might be more promising. - dialect - variant [I am tempted to list "deviant," but we should save discussion about deviations to apply to all deviations around fully-implemented strictly-conformant documents consumed and produced by a processor.] If there was a term that reflected how a strictly-conformant document is obtained by reducing out the foreign matter, that would help too. I thought of "reduced conformance" but that is off base, even though it might be the right kind of tone. Oh, how about "conformable?" -----Original Message----- From: Michael.Brauer@Sun.COM [mailto:Michael.Brauer@Sun.COM] Sent: Thursday, February 05, 2009 05:24 To: OpenDocument Mailing List Subject: [office] Conformance Clause proposal, Version 8 Dear TC members, when I look over the discussions regarding the conformance clauses, it seems to me that there is actually a very large area of consensus, and that there are only a few, but essential items where the opinions differ. These are: - Should there be a loose conformance level for documents that allows foreign elements everywhere? - Can we remove that level, that we had in ODF 1.1, without prior notice? - Should/Can we demand that a conforming producer must be able to create (strictly) conforming documents? In addition to this, there seems to be a strong demand for a conformance level which does not allow foreign elements, and also for having a very limited number of conformance level. My impression is that we agree all agree on this. The requirements are to some degree conflicting, but I anyway tried to find a solution that may be acceptable to all of you. The key points of it are: - There will be two conformance levels for documents. One does not support foreign elements and is called "OpenDocument document conformance". The other one does support foreign elements without restrictions and is called "OpenDocument Host Language Conformance". - There will be two conformance modes for producers. A conforming OpenDocument document producer must be able to produce conforming OpenDocument documents. A conforming OpenDocument Host Language Producer must be able to produce OpenDocument Host Language Documents, but there is no requirement that it must be able to produce conforming OpenDocument documents. This proposals meets the requirement to have a strict OpenDocument conformance, but it also provides a conformance mode for application that wish to extend OpenDocument. This means that we have two conformance levels rather than one, but the new name of what I called "loose" conformance in prior proposals better reflects the characteristics of this mode. And it lowers the risk of confusion. The proposal also provides a conformance mode for ODF 1.1 documents that contain foreign elements and shall be adapted to ODF 1.2. The new name "OpenDocument host language conformance" is actually a name I have adopted from the XHTML 1.1 specification, which provides a "XHTML host language document" conformance level. It describes XHTML documents that make use of extensions modules. In so far, we would be very close to XHTML in this regard. The update proposal can be found here: http://www.oasis-open.org/committees/download.php/31052/conformance-definiti on-proposal-v8.odt The version I'm referring to is the first one in the document. I have made a few non substantial corrections and clarifications, most of them have been suggested by Rob (Rob, thanks for having a close look at the proposal). A list of these changes can be found in the proposal itself. I would be glad if this proposal is acceptable for all of you and would like to discuss and maybe vote on it on Monday. Best regards Michael -- 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]