project

From Microformats Wiki
Revision as of 19:30, 16 January 2008 by Tantek (talk | contribs) (prev revert: there is no hToDo microformat. this edit: edited intro, add problem statement, scenarios section, move statement of intent accordingly, add process items to to-do, reword notes)
Jump to navigation Jump to search

Project

This is a page for tracking the effort to develop a project microformat for authors and publishers to markup public projects like open-source software or other kinds of artistic distributions.

Per the microformats process. Start always with number one.

The Project-*

  1. *examples
  2. *formats
  3. *brainstorming
  4. hProject
  5. faq
  6. *implementations
Please read process first, before creating new pages!

problem statement

scenarios

One of its primary intent is to allow robots to automatically classify projects in a freshmeat manner by browsing the web. ZimbaTm 08:31, 12 Jan 2008 (PST)

real world examples

Please document in project-examples per process.

existing formats

Please document in project-formats.

Related microformats

brainstorming

Please document in project-brainstorming.

markup sample

Note: this markup sample is not based on any project-examples implied schema, and therefore is an a priori brainstorm that is not suitable for a microformat.

<div class="project" id="urn:uuid:233f6e5d-2ad2-4b7e-a3fe-1b90ef2fef57">
  <img class="logo" src="..." />
  <span class="name">Microformats</span>
  <span class="desc">An initiative to extract common patterns from POSH</span>

  <h1>Some informations</h1>
  <a href="http://microformats.org/" rel="home">The primary home page of the project.</a>
  <a href="..." rel="source">Here you can find its source code.</a>
  <a href="..." rel="release">Get the releases.</a>
  <-- Every hCard is looked as a participant [including venues? ] -->

  <h1>Project's tags</h1>
  <ul>
    <li class="tag">open</li>
    <li class="tag">format</li>
    <li class="tag">standard</li>
  </ul>
</div>

CSS selection specification

Note: this markup sample is not based on any project-examples implied schema, and therefore is an a priori brainstorm that is not suitable for a microformat.

A good way to describe the structure, is to look at it trough the view of CSS selectors. Designers sometimes need wrappers, which makes it hard to keep a strict structure. If you used jQuery, you know what I mean.

.project[@id] : is an UUID (see http://ietf.org/rfc/rfc4122.txt).
A unique identifier for the project.
It is used to resolve name clashes.
.project .name : the content describes the project name.
Should not appear more that one time per project.
.project IMG.logo : the src is a link to the logo.
Can have different sizes with by adding "low | mid | high" classes.
.project A[@rel=home] : a project's home page
.project A[@rel=source] : a link to the project's source.
If it is a scm, it is generally solved by using different uris.
Like git:// or bzr:// or http+git://
.project A[@rel=release] : the linked pages contains file releases.
This page can contain hRelease microformat.
.project A[@rel=...] : many extensions can be imagined, like :
 "blog | wiki | parent-project | ..."
.project .tag : the content describes a project tag. You can
have as many as you wish.

to-do

Notes

Please, keep the format simple. The current brainstorms above don't follow an existing standard (existing standards must first be documented in project-formats before proceeeding). It is preferable to re-use and develop minimal modules rather than being verbose. Are these bad or good for example: the uuid:.. or scm:// ones ?

Related ideas

  • Release: semantic description of a project release. Possible usages : automatic tracking and/or conversion for package managers, automatic platform/mirror selection for download managers.