Description: ------------ See also #13187 DOAP (Description of a Project) is an RDF schema for describing projects. We're currently outputting FOAF to describe developers (map output), and RSS 1.0 for news/package releases. Since we've got a well defined package.xml format; we should think about other ways to translate it into something readable by other user agents (via GRDDL) or outputting it.

(To explain further) The xmlns for our package.xml is http://pear.php.net/dtd/package-2.0 If we were to host a document, with a grddl:namespaceTransformation="package2rdf.xsl" element in it at that location, then user agents could translate our package.xml information into something they understand - RDF. See also: http://dannyayers.com:88/xmlns/hdoap/profile/ http://www.w3.org/2003/g/data-view http://www.w3.org/TR/grddl/

Attachment is a XSL transformation for a package.xml 2.0 file -> DOAP.

Any reason why you only loop over the leads of the package ? Never really looked at the DOAP format, that's why I ask. XSL looks cool but then we'd have to make the package.xml available on the website I believe since I think we can't really expect them to download a tar and extract, can we ? ;) I think this is the closest we have atm http://pear.php.net/rest/p/auth/info.xml Wouldn't it be more beneficial to publish our own DOAP files, or perhaps a DOAP + package.xml (the most current one) and that XSL, give people the choice, what do you think ?

> Any reason why you only loop over the leads of the package ? Lazyness. I'll address with a new patch. > we'd have to make the package.xml available on the website I believe since I think we can't really expect them to download a tar and extract, can we ? ;) http://pear.php.net/bugs/bug.php?id=10949 may cover this > I think this is the closest we have atm > http://pear.php.net/rest/p/auth/info.xml Oh, I had no idea about that. Stupid question, why does it re-publish in a different schema, rather than just package.xml *and* a few extra enhancements? (I imagine to make implementation easier) I'll quite happily do up an XSL for http://pear.php.net/dtd/rest.package which also spits out DOAP. > Wouldn't it be more beneficial to publish our own DOAP files, or perhaps a DOAP + package.xml (the most current one) and that XSL, give people the choice, what do you think ? I'm mixed on this. I suppose the main argument for "just put a transformation up and GRDDL aware clients will know how to deal with it" would be "this means less maintenance". IE, if we implemented a namespaceTransformation, + relevant XSL, *every document that ever (or ever did) references http://pear.php.net/dtd/rest.package as an xmlns* can be transformed. If we were to just go for straight DOAP (heh), that's two sets of XML outputs to maintain, across different software versions, etc etc etc.

1) I've amended grokPEAR to add in other people's roles. 2) I've amended http://pear.php.net/dtd/package-2.0.xsd slightly to include a GRDDL namespaceTransformation http://pastebin.com/f8af4d56 3) And the final trick would be to make http://pear.php.net/dtd/package-2.0 serve up package-2.0.xsd

What's the preferred method: * a .htaccess file with a type map, * writing changes to the httpd.conf at installation time * a PHP file which does a header("Location: package-2.0.xsd"); See also http://httpd.apache.org/docs/2.0/content-negotiation.html#negotiation

apache conf is our main way to go; We can't change the xsd file just to add this; at least I see no point in it annnndddd it means we have to provide the package.xml right ?

Also don't you think the DOAP should update when I add a new dev or promote/demote people or change the summary / desc on the project ? If we went with a package.xml approach then we'd have to regenerate it or keep the doap out of date until there's a new release, not sure how feasible that would be in the grand scheme of things.

> We can't change the xsd file just to add this; Out of curiosity, will it break anything in PEAR? Since it's in a different namespace, it should be largely ignored by most XSD consuming tools... > If we went with a package.xml approach then we'd have to regenerate it or keep the doap out of date until there's a new release For the low cost of implementation (small xsd change, webserver redirect) vs the understandable RDF you can extract, I'd say that accepting possibly out of date data isn't such a bad thing. We don't even have to actually publish the package.xml at the moment. It's already available via cvs.php.net. Smart tools can stumble across the package.xml's and do the GRDDL as needed; or at a later date we can explicitly publish them...

Oops, needs a space Index: public_html/package-info.php =================================================================== RCS file: /repository/pearweb/public_html/package-info.php,v retrieving revision 1.153 diff -u -r1.153 package-info.php --- public_html/package-info.php 19 Jan 2009 02:22:36 -0000 1.153 +++ public_html/package-info.php 3 Feb 2009 13:24:56 -0000 @@ -179,7 +179,7 @@ $name = htmlspecialchars(strip_tags($name)); -$doap = 'profile="http://purl.org/stuff/hdoap/profile"'; +$doap = ' profile="http://purl.org/stuff/hdoap/profile"'; if ($version) { response_header($name . ' :: ' . $version, null, $trackback_header, $doap); } else {

This bug has been fixed in SVN. If this was a documentation problem, the fix will appear on pear.php.net by the end of next Sunday (CET). If this was a problem with the pear.php.net website, the change should be live shortly. Otherwise, the fix will appear in the package's next release. Thank you for the report and for helping us make PEAR better.