meta-field and more...

[Elias Torres <eliast@us.ibm.com>]

I had a good meeting with Svante today regarding questions he had
m:data-type m:data-value. I think we have settled those and he'll propose
some changes to the document for your review.

However, we stumbled on one things towards the last half of our call. Now
that we have text:meta-field, we have some disagreements on how it needs to
be defined and how much of it do we define.

This is how I understand it:

Long, long ago, in ODF, we had text:date-field, text:creator-field,
text:whatever-field. This is very cumbersome and doesn't scale. We had to
wait for each ODF specification revision/iteration to get new fields.
Hence, we are proposing text:meta-field. A field that's extensible via our
metadata specification.

Instead of

<text:date-field>2005-01-02</text:data-field>

We have (in content.xml):

<text:meta-field xml:id="foo">2005-01-02</text:meta-field>

In the manifest.xml:

<odf:Element odf:refid="foo" rdf:about="urn:foo" />

In a metadata file (fields.xml):

<urn:foo> rdf:type <http://oasis.org/odf/document/Date> .

A bit more verbose (okay, a lot) but at least it scales with application
needs. The options are probably infinite on how people can define/extend
their fields, e.g. Bruce's citation.

So a couple of questions:

- How do we define this new construct (text:meta-field) ?

- How is this ANY different from <text:span
xml:id="foo">2005-01-02</text:span> ?

In my opinion the only difference is that span is user-editable and the
field is read-only. That should be our definition.

Now to the disagreement part....

First, Svante mentioned that there were some objections in defining it this
way. I would like to revisit it. My main argument is that if it's not the
behavior of the field (editable vs. read-only) then there's nothing (at
least semantically) that makes them different and if not, we should toss
away text:meta-field.

Secondly, Svante would like to define a binding/attaching mechanism for
plugins to text:meta-field. I argue that this is outside of our scope and
it's application specific. If applicatoins (like OO and KOffice) want to
interoperate they have to define their own spec to do so, just like Bruce
is building his own spec to define the metadata for Citations. We are just
coming up with the extensible mechanism for people to define metadata and
for agents to extract it. I don't believe we should be defining much more
than that.

If we begin specifiying plugins, etc, then we are in danger of specifiying
the whole thing, such as how do we load those plugins, find them, metadata
for them, etc and that quickly falls outside of the scope. Just like our
examples, are informative, others have to build their specs for citations,
clinical data, legal documents, etc.

What does everyone think?

-Elias