Hi Rob,
On Monday 9. February 2009 19:58:04 ext 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
