You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@corinthia.apache.org by jan i <ja...@apache.org> on 2015/08/08 19:39:08 UTC
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.
Re: Problems with "Optional" in the ODF and OOXML standard.
Posted by jan i <ja...@apache.org>.
Thanks for a swift very interesting answer.
On 8 August 2015 at 20:01, Dennis E. Hamilton <de...@acm.org>
wrote:
> 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.
>
Aytha@ Optional in your document
>
> 2. Implementation-defined. An application-dependent case where
> implementations must provide documentation of what their specific behavior
> is.
>
Aytha@ Application defined in your document
>
> 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.
>
Aytha@ Optional in your document
>
> 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).
>
Aytha@ Optional in your document
>
> 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.
>
Aytha@ this should be at the bottom of the optional table, since we cannot
know in advance how the implementation expands the standard
>
> 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.
>
thanks but the current scope is not to make the actual comparing, but just
to provide the tables needed to do so in an oderly fashion.
>
> 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.
>
Agreed, I have just experienced it with the low level zip implementation,
but luckely that is another project later.
thanks again
rgds
jan i.
>
>
> -- Dennis E. Hamilton
> orcmid@apache.org
> dennis.hamilton@acm.org +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:jani@apache.org]
> Sent: Saturday, August 8, 2015 10:39
> To: dev@corinthia.incubator.apache.org; Aytha E <ay...@gmail.com>
> 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.
>
>
RE: Problems with "Optional" in the ODF and OOXML standard.
Posted by "Dennis E. Hamilton" <de...@acm.org>.
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
orcmid@apache.org
dennis.hamilton@acm.org +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:jani@apache.org]
Sent: Saturday, August 8, 2015 10:39
To: dev@corinthia.incubator.apache.org; Aytha E <ay...@gmail.com>
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.