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: [Fwd: [office-comment] Public Comment]

Dear TC members,

we received the attached comment regarding our specification.

My proposal for a feedback to this comment is:

First of all, the intention behind the conformance rules in section 1.5
is to specify how the OpenDocument format can be extended. Such
extensions usually would be implemented by adding a certain, well
defined set of elements and attributes to the OpenDocument schema. Such
extended schemas could be future OpenDocument specifications, or other
schemas based on the OpenDocument schema. It is assumed that there are
applications that interpret the extensions, as well as at least a subset
of the OpenDocument schema. That is, the extensions actually specify
certain new features.

What is not the intention of section 1.5 is to specify a "custom schema"
feature for office applications. A "custom schema" feature could be
described as feature that allows to add "custom" markup within an office
application or some other editing environment, that has no meaning for
the application itself except being there.  The proposed change seems to
be a proposal related to custom schema support. Caring about such
"custom schema" support actually is on the agenda of the OASIS
OpenDocument TC for a future version of the specification.

Regarding section 1.5 itself: The Open Office TC decided to use the term
MAY rather than MUST (or will) at the mentioned location, because it
wanted to ensure that the OpenDocument specification can be used by as
many implementations as possible. This means that the format should also
be usable by applications that only support a very small subset of the
specification, as long as the information that these applications store
can be represented using the OpenDocument format. A requirement that all
foreign elements and attributes must be preserved actually would mean
that some applications may not use the format, although the format
itself would be suitable. Therefor, we leave it up to the
implementations, which elements and attributes of the specification they
support, and whether they preserve foreign element and attributes. Some
more information about this can be found in appendix D of the specification.

Best regards


-------- Original Message --------
Subject: [office-comment] Public Comment
Date: Thu, 20 Jan 2005 13:01:09 +0000
From: comment-form@oasis-open.org
Reply-To: christopher.crowhurst@thomson.com
To: office-comment@lists.oasis-open.org

Comment from: christopher.crowhurst@thomson.com

After internal review of the specification we have the following comment
"Microsoft Office 2003 includes support for foreign elements and
attributes. Excel and Word will ignore and preserve these elements when
opening and saving. This is useful because it means you can include
proprietary markup in your Microsoft Office documents, and you can count
on Excel and Word handling this markup properly (i.e., not choking on it
or deleting it). The OpenDocument specification states only that
"Conforming applications that read and write documents MAY preserve
foreign elements and attributes." This means that conforming
applications would not be required to preserve foreign elements. With
respect to our e-Tool products, this might be a problem since we make
use of custom proprietary markup in the Word and Excel templates we
create for our customers."

Can the MAY become a WILL?

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