<ge> + 1 for Michael's response.
Now that i've read his comment, my take on what Christopher
is trying to do is that he simply wants to embed foreign elements and
attributes in a form or template, and have the consuming application ignore
them. The additions (foreign elements) are perhaps only there for subsequent
processing by the eTools application. They are not intended as contextual or
content based instructions for the consuming application. The kind of
instructions a form or template might want to pass through to the application
in order to render a proper interface. Which is where Xforms capabilities
become important.
What he seems to be asking for is a way to pass embedded
processing information through the consuming application, without notice or
action, yet attaching it (preserving it) to the file format so that the
e-Tools application can perfect its processing needs after the fact of user
interaction. Kind of an interesting example of inter application
cooperation using the OASIS OpenDcoument file format.
Maybe what Christopher needs is a way to mark foreign
elements (custom or proprietary mark up) as items the consuming application
“must” ignore, but preserve? Instead of making demands on consuming
applications as to how they deal with foreign elements, perhaps there's a way
to shift the burden back to the template writer, enabling them to specify
exactly how they would like the consuming application to deal with foreign
elements?
What do consuming applications desire/need from template and
form writers? Is there a common layer that allows applications to specialize,
yet conform to the OASIS OpenDocument spec? Does it make sense to caution
consuming applications that there might be three choices to consider:
ignore/preserve all foreign elements, choke, or follow template instructions
to ignore/preserve?
I also wonder if the kind of “static” processing information
Christopher might have in mind more properly belongs in meta data?
(Information about the document rather than the document content or context).
Good response Michael. After considering Christopher's
request, i don't think a discussion about Xforms applies to his problem. And
the UBL type issues seem similarly irrelevant.
~ge~
<Michael Brauer>
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
Michael
-------- 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?
To unsubscribe from this mailing list
(and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/office/members/leave_workgroup.php.