 |
Original Specification:
The original specification put everyting in manifest.xml. This proposal moves most of the elements to the metadata.
Entities that should be in the metadata schema:
- the "source" URL of the package, including format (e.g. cvs, jar, etc)
- the "binary" URL of the package
- the names of and the links to the archive license, change log, bugs, authors.xml, todo list, status
- the charset of the documentation
- the program that generated the file
- a DTD version number. As the requirements for the metadata.xml file changes, we need to ensure that programs using these files can handle deprecated versions
- target languages as defined in RFC 3066 (BCP47)
- a proper namespace. The metadata namespace will be http://www.cjan.org/schema/2003/Metadata
Entities added to the schema since the original specification:
Proposed entities
Rationale
Perhaps authors could go in the jar itself - we could expect the release manager
get authors exactly right and if they get it wrong then tough - have to do a new
release. However, it would be better from a data management point of view if
this could be updated as people change names or if there was a typo. It would be
annoying if searching for Pinckernell showed 5 projects, but I had to search
for author Pinkernell to find the one I was looking for, and that author had
apparently only written this one API.
Organizations change their names, so again from a data management viewpoint
it would be nice to be able to update 3 year old releases by Sun Microsystems
so that a search for Sun|Apple Alliance (fictional!) showed all their software
past and present.
Todo, bugs, issues - it would be cool if these could be updated by integration
with bug tracking systems, etc.
Licenses - I could go either way on this one. Does adding additional licenses or
changing the license require a new release?
|