OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

oic message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [oic] interop profile or interop advisories ?


Hello Dennis,


thanks for the comments,

>  1. "Interop Advisories" is a new idea and I don't know that we have
> thought it through, including whatever the workflow is, where/how they
> would be published, accompanying material, etc.
(...)
>  3. I note that we have wandered a long way from the notion of test guidance
> for assessing conformance and interoperability.  Perhaps something that
> would go with a profile is ways of demonstrating adherence or lack thereof.

The background of the profile is a bunch of things discovered during testing
(like plugfests, but also sitting here behind my very own desk :-)

What we could do is to create an "advisory" and publish a very small test
document (hand crafted, or using a low level library or whatever, I'd rather
not use a office suite, just to keep things neutral) that can be used to check
one's favorite implementation.


> I don't know if Test Assertions work here, but it is a reasonable question.

It might work in "some" form, my guess is that most of the time there won't
be an authoritative statement in the ODF spec to refer to.

- the ODF specification might not provide any guidance for a certain feature
or consumer/producer behavior.

For instance, suggesting that Producers that do not support change tracking 
should hide <text:tracked-changes> when viewing an ODF document. This
seems "obvious", but it is based on a real world scenario were a colleague
of mine was viewing a document with a lightweight editor showing "garbage"
on top of the first page (which turned out to be the content of said element)

- the ODF specification might just use "should...." , or use a non-normative
text

For instance, including a <draw:image> in PNG/SVG for embedded objects.
The spec "recommends" it, but it might be useful to "strongly advise it" (or
whatever the exact wording is) in an Advisory to remind implementers of the
importance of this recommendation, because it turned out to be a real-world
issue.

This is a case where a document / implementation is technically conformant,
but not necessarily interoperable (not sure how you express that in a TA)



Best regards,

Bart


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]