Murdos’ blog

DOAP is a project to create an XML/RDF vocabulary to describe open source projects.

In addition to developing an RDF schema and examples, the DOAP project aims to provide tool support in all the popular programming languages.

Initial goals include:

* Internationalizable description of a software project and its associated resources, including participants and Web resources
* Basic tools to enable the easy creation and consumption of such descriptions
* Interoperability with other popular Web metadata projects (RSS, FOAF, Dublin Core)
* The ability to extend the vocabulary for specialist purposes

Use cases for project descriptions include:

* Easy importing of projects into software directories
* Data exchange between software directories
* Automatic configuration for resources such as shared CVS repositories or bug trackers
* Assisting package maintainers who bundle software for distributors

Quelques articles d’introduction à RDF :

• “An no-nonsense guide to Semantic Web specs for XML people (Part I)” par Stefano Mazzocchi, à l’origine de Cocoon
• Article de Linux Gazette à propos du web sémantique
• Une présentation parue sur XML.com

Présentation de Norman Walsh à propos de la future version de DocBook (5.0) qui sera formalisée uniquement en Relax NG.
Il y explique ce choix, montrant les avantages apportés par rapport à l’utilisation de DTD, et évoque également l’obtention de DTDs et de W3C Schemas à partir des schémas Relax NG.

There are a number of code generation options for Java development. These range from canned solutions that generate whole applications (e.g. Compuware’s OptimalJ), to open source generators (e.g. XDoclet), to custom-built solutions. This article focuses on using XSLT to build custom generators.

There have been a few public attempts to define an effective subset of W3C XML Schema for general usage, most notable have been W3C XML Schema Made Simple by Kohsuke Kawaguchi and the X12 Reference Model for XML Design by the Accredited Standards Committee (ASC) X12. However, both documents are extremely conservative and advise against useful features of WXS without adequately describing the cost of doing so.

This article is primarily a counterpoint to Kohsuke’s and considers each of his original guidelines; the goal is to provide a set of solid guidelines about what you should do and shouldn’t do when working with WXS.