[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office-metadata] meta-field and more...
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]