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

[Bruce D'Arcus <bruce.darcus@OpenDocument.us>]

On Dec 20, 2006, at 2:03 AM, Michael Brauer - Sun Germany - ham02 - 
Hamburg wrote:

>> 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.

OK :-)

>> 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.

That makes sense. In some cases, there will be complex metadata 
required for that, and in others simple strings.

> 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.

OK.

> 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.

My argument is that in general we want the metadata apart from the 
content, but:

a) to properly reference even resource descriptions (say in a field) we 
need a generic mechanism to do that which requires more than just 
xml:id

b) there may be cases (perhaps Elias' demo today) where we need the 
triples themselves -- which is to say properties that relate to 
subjects others than the document -- in-content,and in those cases it 
makes sense to allow for a few metadata attributes to do this.

In other words, this is why I call it the "hybrid" approach.

> 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.

If we have this:

<text:link
	meta:property="http://ex.net/client";
	meta:resource="http://ex.net/contacts/1";>Jane Doe</text:link>

... the actual description (say a vCard representation) is apart from 
the content, but we still have *some* metadata there. The string "Jane 
Doe" is just a label (not per se metadata).

This is what I think Elias means by the in-context metadata idea. It's 
similar to your description of fields.

> 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.

How does the above example work?

> But my questions also have an implementation background.

Yes, I was gathering that.

> 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.

I think the design ideally is agnostic about that, but clearly in our 
proposal we are expecting applications (if they want to support 
metadata) to be able to store those attributes on content nodes and be 
able to understand the relations between them. At minimum applications 
should preserve those attributes.

> If this is the case, then the question is, who cares about the 
> metadata if the document
> is edited?

Good question :-)

> If we have the metadata inline, then the office application has to care
> about the metadata.

They have to care, I guess, about the triples, in the same way that if 
we only used xml:id, they'd have to care about the id. So, yes.

> 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.

This implementation point is certainly worthy of further discussion.

> 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.

Good :-)

Bruce