metadata in xdg-specs

[Aaron J. Seigo]

On Tuesday, January 11, 2011, Cornelius Schumacher wrote:
> On Tuesday 11 January 2011 Aaron J. Seigo wrote:
> > anything else that should be included? any thoughts on format?
> 
> For reference here are some proposals from a while ago:
> 
> http://gitorious.org/~cornelius/xdg-specs/xdg-specs-spec0
> 
> Especially a proposal for a process including how to deal with metadata:
> 
> http://gitorious.org/~cornelius/xdg-specs/xdg-specs-
> spec0/blobs/master/specifications/SpecificationProcess/specification.txt
> 
> Not sure how much of that still is relevant, but maybe it helps in some
> way.

i just (re-)read the spec process file and imho it's still 100% relevant.

what we need is someone(s) from the GNOME and the KDE commuities to offer 
feedback on it and if/once we get to agreement on it, let's simply start 
putting it into practice.

hopefully Vincent or another GNOME developer can aid in bringing the GNOME 
perspective to it?

the xml format could probably use with some tweaks and a proper description of 
the syntax could be created as well once agreed upon. some initial thoughts:

* authorinitials probably not needed?

* in my initial test implemention, using UIDs from a vcard proved nice for the 
machine (e.g. to generate reports) but not so great for humans. :) so perhaps 
instead of vcard UIDs we could just put names and enforce a convention that 
the name as written in the xml file must match an entry in an addressbook we 
keep centrally somewhere. i think we can rely on people not to change their 
names very often ;) .. email addresses, etc. are more transient, though, and i 
still think we should avoid sprinkling them around in documents

* the contributors section duplicates what is in the docbook formatted spec 
itself, so perhaps we can just drop that entirely for now. it'd be nice to 
have, but we can probably rip through the docbook sources to get the same 
information for report generation. as long as the authorship info stays in the 
docbook, there's really no point to duplicating the info. i would like to see 
clear maintainership notes in the docbook, though.

* whether revhistory is needed here or not probably depends on how we handle 
the git repository itself. e.g. if only "release" and "patch level" versions 
of a spec are committed to master, then we can use git log for that instead.

otherwise, i'm still in favor of the approach (as is probably completely 
evident by now ;)

-- 
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
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freedesktop.org/archives/xdg/attachments/20110111/6d5ed9ba/attachment.pgp>