OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: [office] Metadata options


Hi

I thought I'd start the ball rolling on metadata in advance of Monday's call. Please forgive the "schema by example" nature of my examples. I would have presented the suggestions in a schema language (DTD, XSD, RelaxNG) but I'm not sure we've decided on one yet.

General thoughts
The metadata model presented in OpenOffice.org XML File Format 1.0 (OpenOffice) is somewhat specific to the OpenOffice applications and should probably be made more generic and flexible.

Option 1
Leave it alone.

Option 2
Leave the existing predefined metadata (meta:generator, dc:creator, etc.) as they are but extend meta:user-defined so it can contain more than just text types. This might be done by typing the element name like this (Note: This example is not intended to be my suggestions for the actual tags and attributes we would use but rather to illustrate the concept):

<meta:user-defined-date name="checkin-date">2003-01-24T13:47:12</meta:user-defined-date>
<meta:user-defined-text name="foo">Some text</meta:user-defined-text>
etc.

Doing this would also require type extending text:user_defined to allow formatting of typed user-defined fields like this:

<text:user-defined-date text:name="checkin-date" text:date-adjust="123" text:fixed="true" style:data-style-name="ABC">01/24/03</text:user-defined-date >
<text:user-defined-text text:name="foo" text:fixed="true">Some text</text:user-defined-text>
etc.

There are probably other good ways to do this depending on which schema language we go with.

Option 3
Same as Option 2 but with the predefined metadata elements limited to only things we think EVERY document needs. For example meta:template is very specific to the OpenOffice application and should probably not exist in a more generic specification. The OpenOffice application could then add its template metadata it using meta:user-defined-text or meta:user-defined-url.

Option 4
Same as Option 2 but extend the predefined metadata elements to an exhaustive set that fits almost every user's needs. This would leave meta:user-defined as a very last resort.
 
Option 5
Move away from predefined metadata completely to a model like in Option 2 but for all metadata elements. This has the downside of moving us away from the Dublin core. On the positive side we would not have to deal with the difference between predefined metadata elements and user defined metadata elements, the schema would be more compact and tools to process instances of the schema would be simplified.
 
Doing this would also greatly impact how we deal with section 3.7.16 of the OpenOffice specification.
 
 
Flame away!
-Phil Boutros
VP, Technology
Stellent Corporation
pboutros@stellent.com


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC