Thanks for a swift very interesting answer.

On 8 August 2015 at 20:01, Dennis E. Hamilton <[email protected]>
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
>     [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.
>
>

Reply via email to