Re: [office] Re: ODF Conformance

[Thomas Zander <T.Zander@nokia.com>]

Hi Rob,

On Monday 9. February 2009 19:58:04 ext robert_weir@us.ibm.com wrote:
> So, I think the draw:engine case would be conformant.  The music:shape one
> would conform to the "extended" conformance class, but would not conform
> to the default conformance class.  That's how I read the proposal.

Where with the current proposal an implementation with the 'extended 
conformance' would still be able to call itself ODF compliant, I assume?

> The intent is to get away from open-ended extension mechanisms and replace
> them with more targeted ones that better express the intent.  For example,
> we could define a shape extension mechanism, or a schema that generally
> specifies an alternative XML encoding  of the same content (MusicML versus
> SVG).  

We (ODF) have a shape-extension mechanism; namespaces work just fine as 
implementations that don't understand it will ignore it. AFAICT technically 
its just a problem for the validation tool; which means we should probably 
extent the tool to have the features we need :)

> But without such a mechanism, an app has no idea whether the 
> foreign element is a script that should be removed for security reasons,
> something that has accessibility consequences, something that must be
> translated when the document is translated, or whether it contains
> personal metadata that should be removed when anonymizing the document.

Yes, I agree.
You say that like thats a problem. Why?
The fear of extending ODF with closed tags is immensely mediated by the clause 
that the implementation should use existing ODF tags whenever possible.
ODF is pretty far reaching already, so I would argue, interoperability wise 
the odf-implementation should be allowed to add features specific to their 
implementation.

KOffice adds a koffice:nodeTypes attribute to its draw:path element because 
that makes editing the individual path-knots more user friendly. You seem to 
argue that this is a bad thing for ODF interop (because koffice would loose 
its status as a pure-odf-writer), why?

I have spent a lot of time reading these threads and maybe I'm missing it, but 
I have not yet seen an example of why we ended up getting a proposal for 
change. What evil usecase did you have in mind? ;)
I'm interrested in your usecase so we can determine if we want to remove 
perfectly plausible and previously correct usecases already in wide use.

> So I guess my questions are:
>
> 1) Is it worth having a better engineered extension mechanism that allows
> the same capabilities as ODF 1.0, but structured in a way that avoids the
> liabilities?
> 2) If so, how long are we willing to wait for it to be designed and
> specified?  I think it would probably take a 4-6 weeks.  We could likely
> get back to a single conformance level if we had a better designed
> extension mechanism.
>
> I have nothing against extensions per-se.  I just want to ensure that they
> are done in a way which will scale with broader ODF adoption and not
> create problems that we'll never be able to solve.  This is one of those
> things we need to get right.

Right, we need to conform to the OASIS conformance rules. I see that point.
I'm still not convinced that your proposal is a good solution to the question, 
it certainly hurts perfectly plausible usecases for KOffice and Qt/Nokia 
directly. And adding shape-extentions is just addressing one of those 
usecases I brought up in my email.

And as I don't just want to put up my hands with "I object" but also want to 
add something that is constructive; what about these points;

I have been talking to an interrested party that want to have a service where 
you can upload an ODF and let it be rendered in all available ODF 
implementations to view interoperability issues. Much like we have for HTML 
on several 3th party sites.

Next to that, if we come up with a set of acid tests that cover ODF, then this 
is something that would help a lot too for letting implementations strive for 
proper rendering. In contrary to html-acid tests, we can additionally test 
the writing of the acid tests to result in not loosing data or similar 
issues. All easy to automate.

And, lastly, here is a point of view that I have had since Marbux suggested 
the same amendment that we have here now. We see a very lively market growing 
for ODF readers/writers. The market is most probably capable of using a 
testsuite and is able to read our open spec to determine which app has a good 
ODF implementation and which one has a buggy one. Is there a reason to 
believe that the market is incapable of regulating itself?

Or, in other words; let the market work its way a little while longer before 
trying to regulate it, please.
-- 
Thomas Zander

This is a digitally signed message part.