project: Difference between revisions

From Microformats Wiki
Jump to navigation Jump to search
m (Reverted edit of VanGore, changed back to last version by Tantek)
(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)
Line 1: Line 1:
<h1>Project</h1>
<h1>Project</h1>
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.
{{TOC-right}}
{{formatset|Project}}
{{formatset|Project}}
'''Please note : This spec is under construction. For now, it is only a dump of ideas.'''
Work to develop a format to describe the various aspects of a public project like open-source software or other kinds of artistic distributions. One if its primary intent is to allow robots to automatically classify projects in a freshmeat <!-- ? --> manner by browsing the web.


== problem statement ==
=== scenarios ===
One of its primary intent is to allow robots to automatically classify projects in a freshmeat <!-- ? --> manner by browsing the web.
[[User:ZimbaTm|ZimbaTm]] 08:31, 12 Jan 2008 (PST)
[[User:ZimbaTm|ZimbaTm]] 08:31, 12 Jan 2008 (PST)


Line 16: Line 19:


== Related microformats ==
== Related microformats ==
* [[hCalendar]] for timelines and milestones (?) and TODOs
* [[hCalendar]] for timelines, milestones, and to-do items
* Ressources
* Resources
** [[hCard]] for attending/participating" people (staff)
** [[hCard]] for participating people
** [[product]] for stuff(?)
** [[product]] for stuff(?)
*** [[rel-payment]]
*** [[rel-payment]]
Line 27: Line 30:


=== markup sample ===
=== markup sample ===
<strong>Note: this markup sample is not based on any [[project-examples]] implied schema, and therefore is an <em>a priori</em> brainstorm that is not suitable for a microformat.</strong>


<pre><nowiki>
<pre><nowiki>
Line 50: Line 54:


=== CSS selection specification ===
=== CSS selection specification ===
<strong>Note: this markup sample is not based on any [[project-examples]] implied schema, and therefore is an <em>a priori</em> brainstorm that is not suitable for a microformat.</strong>


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.
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.
Line 74: Line 79:


== to-do ==
== to-do ==
* [[project-examples]]
* [[project-formats]]
* Lots of discussion I guess, to satisfy different kinds of projects
* Lots of discussion I guess, to satisfy different kinds of projects
* Semantic approval of experts
* Semantic approval of experts


== Notes ==
== Notes ==
Please, keep the format simple. Unlike hCard, it doesn't follow an existing standard, which permits to keep it simple. I'd much more prefer to develop sub-standards instead of being verbose. For example, the uuid:.. or scm:// ones.
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 ==
== 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.
* Release: semantic description of a project release. Possible usages : automatic tracking and/or conversion for package managers, automatic platform/mirror selection for download managers.

Revision as of 19:30, 16 January 2008

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.