Our discussion on the Wiki example

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

Hi group,

I would like to clarify some of my comments I had on our last call, when we discussed the Wiki examples .

My first comment was about the URI in meta:about. The reference between content element to the manifest, has only to be unique on document package level and therefore should use easier naming.
Instead of "meta:about="urn:uuid:fe107eb0-7704-11db-9fe1-0800200c9a66", we might use in our case meta:id="citation". It's mnemonic and the value of the meta:id (which is not a xml:id as it does not have to be unique, when expressing a type) would be offered during meta data creation by the ODF application component, which is responsible for this type of meta data.
By this it is imaginable that even the implementation of metadata is being exchanged in meta.xml, without a byte changing in the content.xml. Imagine implementations like vcard vs. hcard.

Second someone would like to link to meta data. Instead of referencing to a certain structure (e.g. third paragraph of the body) a link to the type of meta data in the package is closer on the desired. Although I have no fool proof implementation by hand (XPointer?), would such approach solve the problem of changing structure. This approach might exist aside of new introduced xml:id, which could be generated by the user when the document is ready to publish. xml:id should be stable similar to the API / interface of a software and therefore handled with care.

And finally, when our goal is to weave arbitrary metadata into ODF in a most simple, generic way, I was distracted by @content - as Bernd as well before

<meta property="cal:dtstart" content="20060508T1000-0500"> 
  May 8th at 10am 
</meta> 

There is detailed redundant information in the attribute and as well there is a blob of data.
I guess we all agreed not to duplicate the information - not to rewrite the date instance in the meta data, but only explain it's meaning by it's meta.xml.
In general I would rather prefer something like:

<text:p meta:id="date">
    <text:span meta:id="month">May</text:span>
    <text:span meta:id="day">8th</text:span> at
    <text:span meta:id="time">10am</text:span>
</text:p>

or shorter using default namespace (and none for the attribute) as

<text:p s="date">
    <a s="month">May</a>
    <a s="day">8th</a> at
    <a s="time">10am</a>
</text:p>  

By doing so, other software aside of the correct plugin, would have a chance to interpret the data.
For example the fall-back plugin of an ODF application (which assist the user in showing / editing meta data, when the correct plugin is not installed / found), would be able to assist the user.
Even more when the the possible set of data (e.g. all month) is defined in an embedded grammar, further features would be possible. For instance 'auto completion' or 'drop down list' for the content of such a field are thinkable for the future even for the fall-back plugin ( but most likely not in it's first version).

PS:
BTW I have started to look for informations to write the spec of the OpenOffice.org meta data 'reference' implementation, which goes even further than our ODF Meta Data SC. For example, embraces problems like copy & paste problems. If anybody knows links to existing data in this area - aside of ours  - and / or would like to provide input please ping me. Thanks in advance!

I wish you all a nice week-end,
Svante