OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

office-comment message

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

Subject: Re: [office-comment] ODF still fails to specify scripting properly (ODF 1.2 CD01)

> And for the 0.01% of ODF users who know what an XML processing instruction
> is, we could restrict these as well.

(Yes, but Microsoft knows about them. And they are specifically in XML to
allow unconstrained application-specific data to be inserted despite any

The point is that the requirement being expressed is something like "There
should be a profile of ODF 1.2 which prevents Microsoft from performing
the kind of 'embrace, extend and extinguish' associated with it in the
previous decade." Whether this embrace and extend would a matter of
malfeasance, habit or accident is not relevant.

However, the concrete mechanism proposed, merely banning foreign elements,
patently fails to meet the requirement.

So let us take the requirement seriously.

To do it is not impossible with XML and ODF, however, both were designed
to be fundamentally open not closed. It involves taking the X out of XML
and the O out of ODF!

So, without going into MCE (which I as I said, I think is necessary too),
what things are needed in order to make it impractical for Microsoft to
embrace, extend and extinguish ODF?

1) For a start, clear normative text saying that in a closed minimal ODF
document, there should be no use of any mechanism to avoid representing
data that could be represented using standard ODF with any other
mechanism, nor any obfuscation or tag abuse. This kind of blanket
statement closes many loopholes.

2) The ODF ZIP file can only use media and files defined by standards.

3) The ODF ZIP file must contain no places where extension data can be

 i) No use of foreign elements or attributes in *any* file in the document
 ii) No use of processing instructions or comments
 iii) No metadata in any media file
 iv) No use of any metadata in the ODF or any media, unless it is defined
in an (open) standard
 v) No use of ODF Bookmarks, unless the values are defined in an (open)
 vi) No saving of application settings unless defined by an (open) standard
 vii) No use of URIs to external files.
 viii) ...possibly a couple of others.

In other words, *no* application data of any kind, *no* non-standard data
or data values of any kind, *no* circumvention of any kind. And this
applies to all files and formats in the ZIP archive.

Rick Jelliffe

P.S. I think my MODUS proposal is better, but it builds on the above, by
making a data/metadata distinction and allowing plurality as long as there
is at least one vanilla form:

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