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 Definitions

Hi Michael (and TC members)...

When we discussed the conformance topic in the last TC call; we (Eric and Stephen) mentioned that while a single level of conformance is a good goal, we had concerns about how this would impact the documents and processes that already exist. After watching the discussion on this topic over the last two weeks, it seems that the decision regarding levels of conformance has uncovered two impact topics that are of great concern to us.

<clips from Michael's email>
- declares the use of foreign elements in <office:meta> and <*-properties> to be deprecated;
- adds a requirement that conforming producers must be able to produce strict conforming documents on demand.

There is a class of potential extensions that will never be appropriate for integration into a broad standard like this, and there needs to be a mechanism by which such extensions can co-exist with the main specification and the documents can remain conformant. Does the ODF TC want to get into the business of having to be the central arbiter/repository for those very narrow extensions. It makes sense for the TC to allow them to exist.

We believe that extensibility is very important to file formats. The X in XML does stand for extensible, after all.  Is the ODF TC proposing to switch to inflexible markup language perhaps? (IFL?).  Of course, I am only joking about the last question... However, the power of ODF as a file format is that it is extensible. The decision to deprecate this feature seems to be in direct conflict with the goals that we are trying to achieve in the OIC TC. How are ODF documents able to achieve true interoperability if they do not allow foreign elements? (Remember, that they will no longer be called "ODF" documents if they use foreign elements).

In talking with the developer community, who will own the responsibility of creating systems, processes and applications that can consume/produce ODF documents, it is evident that the use of foreign elements is a breeding ground for things that might eventually belong in the spec, which leads to an evolving specification that keeps getting better. In the last TC call, I heard someone make the argument that "people can join the TC and make proposals". At first this sounds like a great idea; however, is it a realistic one? Do most developers even know that this TC exists? Is OASIS prepared to support 1,000's of developers joining the TC? Is this TC prepared to receive, discuss and decide on the 10's of thousands of proposals that could come from that approach?

We think it makes sense to have a conformance class wherein such extensions are explicitly disallowed (like the "strictly conforming" class in the document), and to require that extensions are implementation-defined (i.e. have to be documented by whomever produces them, vs. left unspecified), and to remove a requirement for round-tripping any unknown content (which is a lot of the proposal). We think that if the conformance clause does allow extensions, it will mitigate some of the concern with some language clarifying that extensions cannot be used to replace something that can be specified using markup defined in the spec, only to specify something that's not part of it.

We can discuss this more via email and in the TC call on Monday. However, we are not able to support this TC in adopting the conformance clause as it is written in the current revision.

Hope you are doing well!


-----Original Message-----
From: Michael.Brauer@Sun.COM [mailto:Michael.Brauer@Sun.COM]
Sent: Wednesday, January 28, 2009 6:34 AM
To: OpenDocument Mailing List
Subject: [office] Conformance Definitions

Dear TC members,

first of all, I would like to thank you for the valuable feedback I got
after we have discussed the proposal in the last TC call.

It seems to me that there are no objects for having only a single
conformance level which does not allow foreign elements and attributes,
but that there are concerns to immediately forbid foreign elements
within <office:meta> and in particular also <*-properties> elements,
where ODF 1.1 explicitly allowed these elements.

I have updated the proposal[1] to reflect this, where I have taken the
variant which did only define a single conformance level as basis.
However, I have re-introduced the notion of a strictly conforming
document, which means that there are two levels again. The one of a
conforming document, and the one of  a strictly conforming document. A
conforming document is one that does allow foreign elements and
attributes within <office:meta> and <*-properties>, and only there,
while a strictly conforming document does not allow foreign elements and
attributes at all. The differentiation is made again using a strict and
a non-strict schema. In this regards, there is no change from ODF 1.1.

The proposal further
- declares the use of foreign elements in <office:meta> and
<*-properties> to be deprecated;
- indirectly adds a requirement to document their use by declaring their
semantic to be implementation defined.
- adds a requirement that conforming producers must be able to produce
strict conforming documents on demand.

I would like to discuss the proposal, and in particular the three items
above, in the next TC call. And unless the proposal requires larger
modifications, I would like to ask for a ballot on the proposal in this

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]