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] Conformance Clause proposal, Version 8


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:


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 

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 Brauer, Technical Architect Software Engineering
Sun Microsystems GmbH             Nagelsweg 55
D-20097 Hamburg, Germany          michael.brauer@sun.com
http://sun.com/staroffice         +49 40 23646 500

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:

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