For ODF 1.2, the categories of conformant documents and compliant processing
are a bit complicated. Here is my understanding.
1. Implementation-dependent. Where an interpretation of some aspect of a
feature (maybe all of it) is dependent on what an implementation does. There
is no obligation to account for that in order to be a compliant producer or
consumer.
2. Implementation-defined. An application-dependent case where implementations
must provide documentation of what their specific behavior is.
3. Optionally Producible. This is a complicated case. First, the schema's
provide a great deal of optionality. So it is necessary to analyze schemas to
see what is required in the case of a given element and its attributes, in
combination with what is specified in the text about those elements and
attributes. Notice that a processor is a compliant producer so long as the
documents it produces are conformant in this manner.
4. Optionally Consumable. This is an extremely complicated case. A consumer
must consume anything that is (optionally) producible in a conformant document.
That is, conformant documents shall be consumed. However there is no
obligation to interpret and preserve all of the features encountered although
those features that are interpreted must be interpreted in accord with the
standard (but 1-2 above might apply).
5. Extensions. There are provision for extension by "foreign" elements,
attributes, and attribute values. These don't happen much but they do exist
and there are some principles that apply to producing and consuming them. They
are essentially implementation-dependent as far as the standard is concerned.
These categories apply to OOXML, more-or-less, but (4) might not be as loose as
for ODF. It is necessary to check. Also, the extension mechanism (5) of OOXML
is much more well-defined, with provisions for graceful degradation when an
extension is not recognized or is unsupported.
As far as I know, the only documentation about what is and is not supported in
OOXML and ODF is provided in documentation produced by Microsoft. I can
provide links to them. I am not aware of any such statements from producers of
ODF-based processors. My own experience of the ODF compliance is that it would
be useful to clarify some of the cases identified as unsupported.
It seems to me that without some grounded tests that confirm interoperability
of various feature cases, it will be very difficult to provide comprehensive
information about differences in implementations of ODF and OOXML.
-- Dennis E. Hamilton
[email protected]
[email protected] +1-206-779-9430
https://keybase.io/orcmid PGP F96E 89FF D456 628A
X.509 certs used and requested for signed e-mail
-----Original Message-----
From: jan i [mailto:[email protected]]
Sent: Saturday, August 8, 2015 10:39
To: [email protected]; Aytha E <[email protected]>
Subject: Problems with "Optional" in the ODF and OOXML standard.
Hi
Aytha, please meet the corinthia team (did you remember to subscribe to the
list?)
Team, please meet Aytha who is doing a academic research to provide us with
tables
on differences in implementations.
We want tables to cover 2 situations:
- Application defined features (in this case how an implementation handles
the feature)
- Optional features (in this case does the implementation handle the
feature).
"application defined" is clearly marked in the standards, but it seems
"optional" are not,
can anybody give Aytha a hand by telling how to identify optional ?
Please remember "reply all" as I am not sure Aytha is subscribed.
thanks in advance.
rgds
jan i.
