Re: [office-metadata] Re: Splitting View and Model

[Michael Brauer - Sun Germany - ham02 - Hamburg <Michael.Brauer@Sun.COM>]

Bruce,

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.

> 
> Bruce
> 

Michael