RE: [office] Conformance Clause proposal, Version 8

["Dennis E. Hamilton" <dennis.hamilton@acm.org>]

No, the definition of file extensions is not a normative part of the IANA
registration.   I looked at the form.  The file extensions section is
optional and simply identifies common file extensions that are in use.  It
does not reserve them or anything.

Jomar's and my observations about this are only material in the case that
there are two levels of conformance defined for ODF 1.2, but I agree that
changing MIME types will completely screw up backward compatibility and we
should not do that.

 - Dennis

PS: I know that OO.o, for example, does not care what the file extension is.
If it is a Zip package, it uses the MIME type to figure out what kind of
document it is and then it opens it properly.  The file extension, on
Windows, will determine whether OO.o is launched automatically, but OO.o has
its own way of deciding what it has been fed.

-----Original Message-----
From: David Faure [mailto:faure@kde.org] 
Sent: Monday, February 09, 2009 03:29
To: office@lists.oasis-open.org
Subject: Re: [office] Conformance Clause proposal, Version 8

On Monday 09 February 2009, Dennis E. Hamilton wrote:
> Because file extensions are not defined normatively

They are, actually, but not in OpenDocument - they are defined normatively
at IANA,
based on a submission by this TC.

> application/vnd.oasis.opendocument.text+ext.

I don't like this - it will break existing applications. And I haven't seen
a justification
of _why_ we should do this. What is the goal there?

> I suppose one could decorate the office:version attribute too, with
> something like office:version="1.2 ext".  

Again, I have to ask about the purpose of this.

On the one hand we are saying that there is no real need for foreign
elements/attributes
(my examples of existing foreign attributes have been answered with better
conformant ways of doing it), only for maybe style-*-properties extension,
and on the other hand we want to define a whole class of documents
(including a different mimetype and a different extension) for documents
with foreign elements/attributes? This doesn't make sense to me.

Unless I'm missing something, there's a huge contradiction between
"extensions are not needed" and "let us define extended documents".

Or is this about style-*-properties extensions? I have to name
koffice-produced
files *.odxt just because I save a harmless
koffice:frame-behavior-on-new-page
style attribute in the style properties, and because of this file
extension/mimetype
those documents will not be opened by any of the existing OpenDocument
processors out there? This makes no sense. We are not changing the mimetype
for each version of ODF either, even though the contents are slightly
different,
that's the whole point of XML's extensibility: a ODF-1.1 processor can give
a shot
at parsing a ODF-1.2 document, so it can also give a shot at parsing a
ODF-1.2
document "with a few extensions", can't it? A new mimetype prevents that
completely
(and will confuse users for no apparent benefit).

Let us define one thing: a document is conformant if it validates against
the schema (=> easy yes/no result), and in the schema we allow extensions
in style-*-properties and metadata.

-- 
David Faure, faure@kde.org, sponsored by Qt Software @ Nokia to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).

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