[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office] Re: ODF Conformance
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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]