Looks good for the most part, but there are a few things to address: `name` should be populated with `project.shortname` while `dc:title` should get `project.name`
Store the result of `self.admins()` instead of calling it multiple times in `Project.doap()` Instead of adding a new library to the requirements, we should use [xml.etree.ElementTree](http://docs.python.org/2/library/xml.etree.elementtree.html#building-xml-documents). For example, the `Application.doap()` method could be converted to the following: ~~~~ :::python def doap(self, parent): """App's representation for DOAP API. :param parent: Element to contain the results :type parent: xml.etree.ElementTree.Element or xml.etree.ElementTree.SubElement """ feature = SubElement(parent, 'sf:feature') SubElement(feature, 'sf:Feature') SubElement(feature, 'name').text = self.config.options.mount_label SubElement(feature, 'foaf:page', {'rdf:resource': h.absurl(self.url)}) ~~~~ I'm not sure about selecting the output format. We have some precedent for using a suffix (i.e., `/rest/p/proj.doap`) in the feeds (e.g., `ForgeActivityController.__init__`), but that seems like it would be difficult to implement in this case due to requiring modifications to the controller dispatch. I've also read some criticisms of including the output format in the URI, and some people recommend using the `Accept:` header, but that makes debugging the APIs in the browser more difficult. If adding `Accept:` header support isn't too difficult, I think that would be worth doing, otherwise, the way it is currently is probably fine. --- ** [tickets:#7208] DOAP API for projects** **Status:** in-progress **Milestone:** forge-backlog **Labels:** allura-api 42cc doap **Created:** Fri Feb 21, 2014 10:04 PM UTC by Dave Brondsema **Last Updated:** Mon Mar 03, 2014 03:57 PM UTC **Owner:** nobody Create a [DOAP](https://github.com/edumbill/doap/wiki) API endpoint for allura projects. I think the URL should be /rest/p/projectname?doap (open to better suggestions). It should be XML that is similar in format to SourceForge (classic) DOAP files like https://sourceforge.net/api/project/name/vivo/doap as much as possible. A number of fields in that are not applicable to Allura, so just don't include them. It is okay for Allura DOAP to continue to use some of the "sf" namespace elements like environment, database, etc (those are all the trove types of a project), as well as sf:awarded (for awards, use the current Allura award system available via neighborhood admin pages). `<maintainer>` is for each project Admin and `<developer>` is for each Developer on the project. In addition to the basics, each tool should be able provide its own XML/RDF data to include. For example, SourceForge's internal mailman tool could provide `<mailing-list>` entries and Files tool could provide a `<download-page>` entry. --- Sent from sourceforge.net because allura-dev@incubator.apache.org is subscribed to https://sourceforge.net/p/allura/tickets/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/allura/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
