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: Re: [office] Metadata options

Hello Phil,

Philip Boutros wrote:
> 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.

I thought RelaxNG was accepted as a working language.

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

I can agree to that. We have been asked by several people [outside of 
OASIS] to improve meta data support, and I would think it fits nicely 
into phase 1 plans.

Two issues that have not come up yet:

One of the more fundamental issues is whether one goes for a generic 
solution [i.e. some form of generic and user extensible meta data], or 
whether the catalog of supported meta should be extended to support a 
fixed (but expanded) set of meta data elements. I think both are doable; 
I personally would prefer a user extensible approach. However, to enable 
any applications to meaningfully deal with meta data, I think a set of 
'core' elements must be defined which every application is expected to 

The other thing is that meta data should be somehow accessible within 
the document. Note that currently every supported meta data element has 
a corresponding text field, which allows references to the document's 
meta data from within the document. (E.g. putting the authors name or a 
(user defined) revision number into the header.) So changes to the meta 
data structure should be reflected in the text fields. For generic meta 
data some sort of generic meta data text field should be specified, too. 
That's doable, but may require some care to make it easy on the 

To comment on Phil's suggestions: On first view, I think fixed meta data 
elements (much like the existing ones) + extensions are the best way to 
go. Number 2) was the closest to this suggestion.


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

Powered by eList eXpress LLC