On Feb 2, 2006, at 5:39 PM, Patrick Durusau wrote:
> Contrast that with:
>
> Your ODF application supports embedded XMP and my ODF application does
> not but preserves it.
>
> Is the second case a lack of interoperability? I don't think so but I
> may have too narrow a notion of what you mean by the term.
>
> I think what you are asking for is a minimum level of feature support.
> OK, but that is a separate question in my mind from interoperability
> and has different drivers.
Hmm ... maybe your distinction above will help clarify the discussion.
For sake of argument:
What kind of document metadata interoperability would ODF now have if
the current schema left all the details up to implementers?
So KOffice described a document title by doing:
<Document title="Title"/>
... OOo did:
<meta:office>
<dc:title>Some Title</dc:title>
</meta:office>
... and the IBM guys decided to do:
<TEXT-META>
<TITLE>Some Title</TITLE>
<TEXT-META>
That's what we risk by not standardizing.
I will tell you my concrete issue with the bibliographic use case:
The current bibliographic market is rather horribly uncompetitive, and
completely focused on MS Word. ODF solutions effectively have no chance
to make any significant inroads in higher ed and research fields
without addressing this.
My contention is that a big part of that problem is a metadata one.
With the dominant bibliographic application, it embeds its own custom
XML-like metadata in a Word field. That metadata conforms to no
standard model or syntax, and so if you want to read it, you need to
write custom code.
It's no wonder, then, that there are few real alternative. I have
literally never met anyone in my field who uses anything but Word.
They are bound to that application because of its market status, and
because the bibliographic application that so many academics rely on is
itself dependent on that application.
This is heavily wrapped up in document and metadata standards (or lack
thereof) too. If User X sends their
specific-application-plugin-enhanced Word file to non-Word + said
plug-in User Y, the doc is basically broken for all intents and
purposes. They cannot collaborate (at the level of the citations and
metadata) unless they use the exact same applications.
OpenOffice, BTW, currently has its own approach to embedding
bibliographic metadata in the content file which is even more
problematic, being just a limited collection of key/values. Metadata --
certainly bibliographic metadata -- is, however, fundamentally
relational in character. Key/values don't go very far.
I have talked to a lot of developers over the past few years who have
tried to provide alternatives, and there are a lot of challenges they
run up against. Metadata is a big one, and they typically invent their
own solutions, or borrow from BibTeX. And many of them would rather not
to have to do that. In fact, it's one of the reasons why BibTeX is so
widely used in some contexts, despite all its problems. Developers say
"ah, the metadata model and syntax is set, and processing tools know
how to use it, so I'll just use that."
I am confident if we tell them "if you would like to be compatible with
ODF, follow these simple rules," they will gladly do so, that the
consistency will encourage a much healthier ecosystem of tools, and
that this will ultimately benefit users, who will have more freedom to
choose their applications; not just editing applications like Writer or
Workplace or KOffice, but applications not yet written that would
interact with those editors.
Bruce
