[
Lists Home |
Date Index |
Thread Index
]
Dare Obasanjo wrote:
> Exactly what is wrong with the "Project Record in XML" from a document
> design perspective?
The main problem is that all the URLs point to a CGI
redirector on freshmeat.net, instead of the real URI:
<url_homepage>http://freshmeat.net/redir/dom4j/16508/url_homepage/</url_homepage>
Further, since they're all uniformly constructed
(http://freshmeat.net/redir/$projectName/$projectId/url_$urlType),
the only useful bit of information you can glean from
the entire element is whether or not there exists
a URL of that category for that project.
Aside from that, the document structure looks suspiciously
like a direct serialization of a badly-designed RDBMS schema --
you can just *tell* that the site is backed by a database
containing something like:
CREATE TABLE project_urls
(
project_id char(32) primary key,
url_homepage char(100) null,
url_project_page char(100) null,
url_tgz char(100) null,
url_changelog char(100) null,
url_rpm char(100) null,
url_deb char(100) null,
url_bz2 char(100) null,
url_cvs char(100) null,
url_list char(100) null,
url_zip char(100) null,
);
A better design (IMO) would be an XML serialization like:
...
element urls {
element url {
attribute role string
& attribute href string }* }
...
where 'role' is one of 'homepage', 'project_page', 'rpm', etc.,
which would be the natural serialization of something like:
CREATE TABLE project_urls
(
primary key (project_id, url_role)
project_id string references project.project_id,
url_role string references url_roles.url_role,
url string
);
Or going even further, the freshmeat.net database would
be a killer app for RDF.
--Joe English
jenglish@flightlab.com
|
