|Subject:||Re: [office-metadata] Re: Splitting View and Model|
|From:||Michael Brauer - Sun Germany - ham02 - Hamburg (Mich...@Sun.COM)|
|Date:||Dec 19, 2006 11:02:59 pm|
Bruce D'Arcus wrote:
On Dec 19, 2006, at 7:59 AM, Svante Schubert wrote:
According to this I would like to move the @content attribute value and the date type completely to the metadata.
As I mentioned before, I think that you and Michael are criticizing our proposal on this count not only doesn't make sense generally (WHERE the
It was not my intention to criticize your proposal, but to understand it. I have to ask for apologies if this was misunderstood.
metadata is ought to be irrelevant from a model perspective), it also contradicts the existing ODF spec. To quote:
"Each field type is represented by a corresponding element type. A field in a document is encoded as a single element of the appropriate type. The content of the element is the textual representation of the current field value as it would be displayed or printed. Therefore, ignoring all field elements and displaying only the textual content of the elements provides an approximate text-only version of the document.
The value of a field is usually stored in an attribute. It is necessary to store the value so that the presentation of the field can be recomputed if necessary, for example, if the user decides to change the formatting style of the field."
This description of text fields is maybe a little bit too simple (and we of course should correct it). Actually it is not the field value in all cases, but the information required to retrieve the field value, except that the field has a fixed value actually. Take the existing meta data fields for example. They by their names reference the document's meta data stored in the meta.xml. The value is only included if the field content was frozen, that is, shall contain the value of the metadata at the time the content was frozen forever. As long as the field is bound to current metadata of the document, the value is only included the meta.xml. Maybe we need the same concept for metadata.
This explains the reason for asking my questions regarding your proposal. Its my understanding that the metadata in your proposal is inline in the content. Please correct me if I'm wrong.
Since we separate content and styles and content and metadata already, I would like to understand where the benefit is of not doing the same for metadata about other subjects than the document. And I would like to provide some hints how we may resolve other requirements, like displaying metadata of other subjects in the content. That's actually all.
But my questions also have an implementation background. It is my understanding that we assume that metadata is not maintained by the office application itself, but by some kind of plug-ins. Please correct me again if I'm wrong.
If this is the case, then the question is, who cares about the metadata if the document is edited? If we have the metadata inline, then the office application has to care about the metadata. It at least has to keep it or has to pass it to a default plug-in when loading the document, and it has to merge it into the content.xml again when storing the document. If we keep the metadata separate, then the office application only has to care about the ids or similar attributes that are used to attach metadata to objects, but not about the metadata. This seems to be more flexible to me.
However, if the SC's discussions reveal that it is the better solution to have metadata also or only inline, then this would be okay for me, too.
Adding a meta:content (or I guess if you prefer meta:value) attribute is fully consistent with the above. So if we exclude it from our spec, should we exclude it everywhere in ODF, deprecating the current fields?
No. Only those fields that have only a fixed value (like a date field) contain the value.