MHonArc v2.5.0b2 -->
office message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Sun's position on specification title & format name + proposal
Hi ereryone,
I'd like to give Sun's position on the naming issue:
It is vital to us, to have 'open' in the name, since this is the whole
point of our effort: a truely open document format. The format is used
for files that are used by, but not limited to office-suite like
applications.
Due to the interest in open document format solutions in
the goverment sector, we want to underline our commitment to such
openness by using it directly in the name. The language used in those
matters explicitly distinguishes a standard from an open standard, e.g.
in the recent discussion with the EC see:
http://trends.newsforge.com/trends/04/11/19/148236.shtml?tid=138
Since we adhere to what the EC defines as an open standard (as opposed
to just a standard) we want to use it in the name explicitly.
Further we'd like to foster adoption by vendors of e.g.
content management systems and archives as well as standalone
text-processing, presentation or drawing applications which might not
natuaraly assoiciate themselfes with the term 'office'. Office
applications are a synonym for desktop document processing - we view
that as an unneccessarry limitation of the scope of the format implied
by a name emphasizing on the term "Office".
We also want to limit association with any existing
product/application like OpenOffice, StarOffice, StarSuite or the
Microsoft family of "Office XML" formats.
If the term "Office" is to be used - as some TC members have suggested,
it should be used only in the context of "Office Applications" and not
at the beginning of the title, in order to limit ambiguity.
We are thus proposing to use
"Open Document Format for Office Applications (OpenDocument)"
as the formal specification title. This is a compromise, which
underlines the openness of the format while keeping the term "Office" in
the title at a position where less ambiguity and limitation is implied.
The short name OpenDocument lends itself well to names for the actual
document types:
OpenDocument Text -> .odt
OpenDocument Text Template -> .ott
OpenDocument Master Document -> .odm
OpenDocument Spreadsheet -> .ods
OpenDocument Spreadsheet Template -> .ots
OpenDocument Drawing -> .odg (graphics)
OpenDocument Drawing Template -> .otg
OpenDocument Presentation -> .odp
OpenDocument Presentation Template .otp
OpenDocument Image -> .odi
OpenDocument Formula -> .odf
OpenDocument Chart -> .odc
respectivly we'd change the term "openoffice" in mimetypes and namespace
URNs to "opendocument"
"OpenDocument Text", "OpenDocument Spreadsheet" with only the type
suffix being translated in internationalized applications e.g.
"OpenDocument Zeichnung" (for a drawing in german)
We think that a short name of "Office Document" or "OfficeDocument" does
not serve this purpose. E.g. "OfficeDocument Text", "OfficeDocument Drawing"
A name stating with "office" is very likley to be confused with the
propriatary format used by the application suite commonly referred to as
"Office".
By starting with "open", we actualy emphasize the fact, that the user
is saving her document in a format that will allow interoperability with
users of other applications/systems.
A name starting in "Office Document(s)" is explicitly not acceptable for
use in sun products.
We have spent great effort in considering other names and have found the
proposed one to be the best. We thus urge TC members to consider
adoption of this proposal.
Furthermore, our legal councel has advised us that we (sun) should use
"OpenDocument".
We ask all TC members to state their positions towards this proposal and
hope to have this question resolve by the time of our next conference call.
Best Regards
~Lars
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]