corinthia-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jan i <>
Subject Re: Problems with "Optional" in the ODF and OOXML standard.
Date Sat, 08 Aug 2015 18:17:15 GMT
Thanks for a swift very interesting answer.

On 8 August 2015 at 20:01, Dennis E. Hamilton <>

> 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
jan i.

>  -- Dennis E. Hamilton
>    +1-206-779-9430
>  PGP F96E 89FF D456 628A
>     X.509 certs used and requested for signed e-mail
> -----Original Message-----
> From: jan i []
> Sent: Saturday, August 8, 2015 10:39
> To:; Aytha E <>
> 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.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message