Re: [office-metadata] meta-field and more...

[Svante Schubert <Svante.Schubert@Sun.COM>]

Elias,

Patrick is reviewing the Spec a last time and an update will be 
published soon.
Some comments on your post:

Elias Torres wrote:
> 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> ?
>   
Remember we decided to see text:span as volatile and only for styles and 
introduced therefore text:meta for as equivalent for metadata.
But your question certainly remains.
> 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.
>   
The ability to be read-only is already quite application specific.

Patrick mentioned two nice arguments to keep the definition to be 
created based on Metadata and not write protect the element:
1) What if the user would like to tweak the generated content before he 
prints it?
2) There is a certain user expectation that elements that had been 
generated are marked. But of course the plugin might even create other 
elements (e.g. a table).
> 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.
>   
You are right that the ODF applications should behave consistently 
especially regarding metadata.
I will try to trigger this in our next development phase.

> 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.
>   
I do not want to specify plugins or other application logic.
What we finally established was a relation ship between the element and 
a named RDF graph, representing a metadata file.
The metadata file can be related upon types to a plug-in.

All ODF applications will be in need of this relation, is this fine for you?
> What does everyone think?
>
> -Elias
>
>   
Svante