MHonArc v2.5.2 -->
office message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Subject: [office] RE: Metadata options - additional options
Title: Message
Option
6
Obviously if we want to move significantly away from
the current OpenOffice spec we can look at the wholesale adoption of a metadata
schema generated by some other body or creation of a totally new metadata definition from
scratch.
-Phil
-----Original Message-----
From: Philip
Boutros
Sent: Friday, January 24, 2003 2:38 PM
To:
office@lists.oasis-open.org
Subject: 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!
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Powered by eList eXpress LLC