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] | [List Home]

Subject: Re: [office] Metadata Fields

Title: Re: [office] Metadata Fields
Has anyone documented mapping the Office metadata to other popular formats such as XMP and MS Office?  Such a matrix might be useful for those who actually have to work with metadata on large scale systems.


On 4/14/09 2:06 AM, "Michael Stahl" <Michael.Stahl@Sun.COM> wrote:

hi Patrick,

On 14/04/2009 02:36, Patrick Durusau wrote:
> Greetings!
> A new issue that I had not previously noted.
> 6.5.1 – 6.5.19, inclusive. All the text in these sections refer to a
> “document.” However, note that all these elements are children of
> |<text:a>| 5.1.4, |<text:h>| 4.1.1, |<text:meta>| 5.1.5,
> |<text:meta-field>| 6.5.19, |<text:p>| 4.1.2, |<text:ruby-base>| 5.4.1
> and |<text:span>| 5.1.3 elements. None of which represent documents.

Yes, these field elements refer to the document that is being edited.
Specifically, their  contents come from the similarly-named elements in

> Could mean the document being edited, but then we would have to say that
> all <text:initial-creator> elements, for instance, must have the same
> value. Since that element may occur as a child of every <text:p> element.

In principle, yes, all such elements would have the same contents.
Except, for those that have the attribute text:fixed="true": these would
have whatever content they had when the field was marked as fixed, which
may well be different in different instances.

> Could mean that the metadata in question applies to the elements specified.
> This problem also occurs with 6.3.6 – 6.3.11, and 6.3.2 – 6.3.5, inclusive.
> Options:
> 1. Say that the metadata fields apply to their parent elements. (Would
> we need to say something about displaying those fields?)
> 2. Could change the schema to attach these fields to elements that
> represent "documents." And to remove them from elements that don't.
> (Note that this would not be backwards compatible.)
> I don't have a default position to suggest. I can't count the number of
> times I have read this section and simply missed this issue.

Well, these fields are intended for _displaying_ information in the
content of the document, where the "canonical" version of the information
is already contained at a well-defined location (meta.xml). So imho we
already have option (2.), and i don't really see a problem here.

> Apologies.
> Hope everyone is at the start of a great week!
> Patrick


Michael Stahl            mailto:michael.stahl@sun.com
http://www.sun.de        OpenOffice.org/StarOffice Writer
Sun Microsystems GmbH    Nagelsweg 55, 20097 Hamburg, Germany
Sitz der Gesellschaft:
Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten
Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer
Vorsitzender des Aufsichtsrates: Martin Haering

To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:

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