[Clipart] Comma-separated keywords in metadata

[Bryce Harrington]

On Sun, 18 Jul 2004, Jonadab the Unsightly One wrote:
> Bryce Harrington <bryce at bryceharrington.com> writes:
> >> Is this format suitable for our purposes?  Could we just re-use it?
> >
> > Yes.
> 
> Is there a spec for it, or is it documented in source code?

The jar file format does have a spec somewhere; I don't know where it is
offhand, but it's used by OpenOffice and was developed for Java
originally.  There's also good tools and programmatic utilities for
operating on them (try hitting CPAN).

> >> Now that I've thought about it further, I'm thinking we require the
> >> licensing to be covered in the metadata.  Do we want to require that
> >> in the package format spec itself, or just for OCAL contributions?
> >
> > Hmm...  I would be tempted to be a little aggressive here and have
> > it required in the package format spec.  That way it eliminates the
> > question.
> 
> What does Inkscape's collection format do in this regard?

The jar-based format used by inkview doesn't impose any content
requirements, so it lacks any knowledge of metadata or licenses.  What
we're talking about here would be augmentations to it.

By the way, the code relevant to this is pretty easy to review in
isolation from Inkscape itself, if you're ok with C++:
inkscape/src/inkview.cpp and inkscape/src/inkjar/*
Potentially, some day we could even think about splitting it out into a
separate utility that could be used both in Inkscape and OCAL.

> >> The thumbnails spec says one .thumbnails directory in one place.
> >> We'll have to adapt it to use a directory inside the package,
> >> though.
> >
> > Can you compose an email to the author of the spec summarizing our
> > issue?  Perhaps we can get a generalization into the spec that'll
> > work for our purposes?
> 
> Yes, I'll get to that eventually.  I'm still figuring out exactly what
> all of our issues are first.

Okay, cool.

> I like to be a little more careful about file format specs than code,
> because for compatibility reasons they're harder and/or more painful
> to refactor when you find the problems as you go along.

Yup, good call.  I agree.

bryce