metadata in xdg-specs
Aaron J. Seigo
aseigo at kde.org
Mon Jan 10 15:45:06 PST 2011
hi all ...
so we now have git://anongit.freedesktop.org/xdg/xdg-specs which is nice to
see. we need to populate it with more of the specifications that are out there
and i hope to have the time/energy to help out again with that.
it is apparent, at least to me, that we would benefit from some formalizations
in the repository. in particular, it would be good to provide some guidelines
as to how to mark "releases" of a specification as well as to have a standard
and machine-readable bit of metadata for each spec in the repository.
marking releases could be done with tags in the repository, but then we'll
want some tag name conventions. personally, i think we'd be better off with
simply creating an in-repository copy of each specification version as that
would allow one to have all versions of all specs easily side-by-side. this is
particularly an issue as there is probably no sensible release cycle that all
the specs could share. and yes, this is certainly not how one does it with
source code, but these aren't programs to compile.
as for metadata, if we have a simple way for people from various projects to
note which specifications are supported and from which version of their
software, we would then easily be able to determine which specifications are
broadly adopted and where. i'm willing to write some simple scripts that run
through such metadata to generate summaries for us, even.
the question there is: what would that metadata look like? imho it should be
both machine readable and easily human editable. it should also contain
information such as:
* the name of the project (e.g. KDE, GNOME, Enlightenment, XFCE, LXDE, etc)
* the current status (rejected, interested, accepted, implemented, ..?)
* the version of the software that the spec has been implemented in, if any;
this probably means also recording which versions of the spec relative to
which versions of the software (e.g. "Foo spec v1 implemented in Bar v6.3; Foo
spec v2 implemented in Bar v7.0")
anything else that should be included? any thoughts on format?
location should be easy enough: a file with a standard name (status? adoption?
metadata?) in the top-level directory of each spec.
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43
KDE core developer sponsored by Qt Development Frameworks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: This is a digitally signed message part.
More information about the xdg