[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: <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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]