I have just picked up this email from my huge backlog. Is this something
we are interested in discussing with the other projects Michiel is
mentioning?
Michiel Leenaars:
Would it be an idea to have a liaison between the Document Foundation
and other projects such as Calligra, AbiWord/Gnumeric, with a named
standards compliance person (and a fallback) within each project, which
take care of monitoring and pushing fixes - given that breaking the
standard is a severe thing that noone wants, and fixing such things is
best done from the inside.
Hi Michiel,
hm - I wonder why we'd need this extra ceremony. From what I can
tell, the problem is not acknowledging the problem, but actually
fixing it.
I've personally addressed a bunch of interop things myself, if and
when my time permitted it (and usually made fixing those a priority
over other equally important tasks). If beyond that there are urgent
issues in LibO that you, or the other ODF-processing FLOSS projects
deem important, I think the most promising avenue to success is to
motivate hackers to come & fix those.
Or is there a recent example where not having such a role was
causing much trouble?
Of course, talking with you, Jos, Ben & others from those projects
on how to improve ODF interop should happen nevertheless - but does
take place, works nice & well, often & informally. 
Cheers,
-- Thorsten
Hi Thorsten,
indeed, as you say so far discussion among the projects has been solved informally (actually my mail to Italo was rather informal as well). I think the members of the TC and the people that attend the plugfests do already carry that liaison role, but (like yourself) they are very busy people. And I would much rather have these people spend their time on writing specifications if the issues are already specified but just have implementation issues. That is not to say that I want you or anybody else to stop doing what comes informally and naturally (certainly not), but to have a tenacious bulldog appointed within these projects that makes sure that progress is made even if people are swamped.
From where I stand (and I'm not part of any specific project) there are a number of interoperability issues at your end still open I think, although probably people within TDF are already working on these. Notably this includes the use of (legacy) SVM wrappers instead of native alternative ODF frames and the lack of support for frame alternatives and clarification of the range selection of clipboard content (the issue that was raised by Gnumeric in August, as you may recall). Also probably some other forward looking capabilities which provide answers to common interoperability issues - like RDF and SVG support, as well as font inclusion - deserve some attention as well. Even though ODF as a document format has plenty of traction, some specific parts such as ODF's 3D objects stand less of a chance to make it as the dominant standard in this area (given that there are far better and more widely used standards for 3D). In order to make the experience better for everyone and make at least the content portable/visible to other (less complete) implementations I think that should be made more robust by making sure there are standards based fallbacks (in SVG, PNG) for any such parts. Those are the kinds of things I would envision the liaisons to discuss.
For people outside the project it is often not transparent who is responsible for what in other projects. Rather than asking people to just file a bug report, it would be good to have a named person in the project that is 'responsible' for this and that has regular contact. That is why I proposed to name a liaison - so there is an acknowledged channel to discuss practical areas of improvement. But of course it is just a suggestion.
Best,
Michiel
Michiel Leenaars wrote:
... but to have a tenacious bulldog appointed within these
projects that makes sure that progress is made even if people are
swamped.
Hi Michiel,
sorry, that's not gonna fly here. Participants in this project are
often self-directed and volunteers, or employees of companies with
very individual priorities & schedules. Having a liaison person that
cannot command resources is then rather pointless.
From where I stand (and I'm not part of any specific project) there
are a number of interoperability issues at your end still open I
think, although probably people within TDF are already working on
these.
If you, or someone else, has such a list, would be cool to have it
filed properly in bugzilla & maybe some meta-issue to track.
Even though ODF as a document format has plenty of traction, some
specific parts such as ODF's 3D objects stand less of a chance to
make it as the dominant standard in this area (given that there
are far better and more widely used standards for 3D). In order to
make the experience better for everyone and make at least the
content portable/visible to other (less complete) implementations
I think that should be made more robust by making sure there are
standards based fallbacks (in SVG, PNG) for any such parts.
Here seems to be some incoherence in your argument (that was
previously asking LibO to fill ODF consumer bugs by completing the
implementation), and then you also suggest we fix things that are
shortcomings in other applications.
Beyond that, while I sympathize with the idea to have a public face
for odf, in practice I prefer less formal roles over more titles. So
for all the other ODF processing project participants that I haven't
chatted with yet, feel free to mention my name as a potential
initial point of contact (or anybody else who'd like to volunteer
here). Even better, encourage them to mail
libreoffice@lists.freedesktop.org with a rough patch, and/or the
willingness to contribute to the solution.
Cheers,
-- Thorsten
Hi Thorsten,
thanks for the reply. I understand now that the structure of the LO project renders my suggestion infeasible. So lets drop it. I will answer your questions below.
If you, or someone else, has such a list, would be cool to have it
filed properly in bugzilla& maybe some meta-issue to track.
I'll try to draw one up with Cor Nouws and the other people from LO that attend the 7th ODF plugfest in Gouda next week (if they have the time for it).
Even though ODF as a document format has plenty of traction, some
specific parts such as ODF's 3D objects stand less of a chance to
make it as the dominant standard in this area (given that there
are far better and more widely used standards for 3D). In order to
make the experience better for everyone and make at least the
content portable/visible to other (less complete) implementations
I think that should be made more robust by making sure there are
standards based fallbacks (in SVG, PNG) for any such parts.Here seems to be some incoherence in your argument (that was
previously asking LibO to fill ODF consumer bugs by completing the
implementation), and then you also suggest we fix things that are
shortcomings in other applications.
Of course, this is another point - however, coming from the same concern which is the experience of the end user. I think it is fair to acknowledge that features like the 3D objects are unlikely to survive in ODF in the long term - and rightly so, for ODF's sake. From a pragmatic point of view these components seem atavistic and without the historicity of Star Division's long gone past in 3D software components their presence in the specification would be hard to explain - let alone justify.
Since it is unlikely that LO will be able to cover the growing billions of electronic devices out there immediately - though I have a great deal of confidence in its unlimited future 
- the high cost of support for other incomplete (non-desktop) implementations and the subsequent lack of it will probably negatively impact the end users perception of ODF and its capabilities to store their content reliably. So my point is that for the sake of the users we should at least be storing any such data in a way even the users of a simple implementation with many shortcomings can still at least see the objects. This would benefit everyone in the long run, I think.
Best,
Michiel