OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [office] Metadata subcommittee discussion

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:

   <dc:title>Some Title</dc:title>

... and the IBM guys decided to do:

   <TITLE>Some Title</TITLE>

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.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]