[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office] Public Comment on Foreign Elements
<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.
<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.
-------- Original Message --------
Subject: [office-comment] Public Comment Date: Thu, 20 Jan 2005 13:01:09 +0000 From: email@example.com
Comment from: firstname.lastname@example.org
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.