Re: [office-metadata] summarizing recent suggestions

[Elias Torres <eliast@us.ibm.com>]

Michael.Brauer@Sun.COM wrote on 02/28/2007 09:21:06 AM:

> Hi Bruce,
>
> Bruce D'Arcus wrote:
> >
> > On Feb 28, 2007, at 8:44 AM, Michael Brauer - Sun Germany - ham02 -
> > Hamburg wrote:
> >
> >>> The above is a generalization of the citation field, adapted for the
> >>> new metadata support. It is also similar to how MS does this, BTW.
> >>> What I encode in two meta:link elements, they encode in a single dumb

> >>> attribute (which would be really ugly to process with XML tools,
BTW).
> >>
> >> Yes, I do understand that, and I have no objections to providing
> >> additional information in the content. But since we have the option to

> >> specify that as meta data, too, I would suggest that we look deeper
> >> into that idea if we agreed on the remaining issues.
> >
> > OK. I just thought you agreed that putting all the field logic (the
> > resource URIs and parameters) outside the content may not be the best
idea.
>
> My reply was confusing, sorry. I think what must have in the content is
> enough information to efficiently update the field. Having some kind of
> type (as suggested by you) and a link to the RDF/XML streams that
> contains the real meta data (as suggested by me) should be sufficient.
> Having just an id that is referenced from an arbitrary RDF/XML stream
> probably isn't.

I'm fine with having a type and xml:id. A link to the RDF/XML is too
constraining. Remember RDF is extensible and triples can come from multiple
files to say that everything is inside one file, it's limiting in my
opinion, but I'd compromise as long as it's a *hint* or starting point and
not restricted to only one file.

>
> Having more information in the content, for instance parameters for the
> string that should be displayed, is a good idea, but I think we can go
> with having that data in the metadata itself, provided that we can
> locate that metadata efficiently.

good.

>
> Is that clearer now?
>
> >
> > That existing fields in ODF don't contain that information in content
is
> > a function of the fact that those fields are really simple, and fixed.
> > What we are providing here is a much more powerful -- custom -- field
> > option, so it makes sense it will be a little more complex.
> >
> > In any case, I'm happy to defer this decision until everything else is
> > settled. Just so long as my use case can be adequately supported in
1.2.
>
> I think this will be the case, since we have already agreed on the
> citation field. It will become part of ODF 1.2 in any case, but we of
> cause have the chance to adapt it.
> >
> > Bruce
> >
>
> Michael
>
> --
> Michael Brauer, Technical Architect Software Engineering
> StarOffice/OpenOffice.org
> Sun Microsystems GmbH             Nagelsweg 55
> D-20097 Hamburg, Germany          michael.brauer@sun.com
> http://sun.com/staroffice         +49 40 23646 500
> http://blogs.sun.com/GullFOSS
>