XML observations: Using XML to describe open source project 1

The great thing about open source projects is their essentially democratic nature: it's easy for anyone to start their own projects, as is often the case! Unfortunately, it can be difficult for users to find software that suits their purpose. This requirement has been met through different software registrations in the past. Perhaps the most famous and oldest software registrations are freshmeat, but there are more, usually for more specialized requirements. For example, free Software Foundation's Fsf/unesco free Software Directory, GNOME Software map, and bioinformatics Software map (RELATED LINKS see Resources).

Now there are so many registrations, whether the timely update has become a real problem. Diligent software maintainers often need to access multiple site updates in each release cycle, not to mention their own Web sites. But such maintenance personnel rarely see, in a register to find the latest information is very rare things. If you take into account the many aspects of modern software projects: mailing lists, IRC channels, Web sites, wikis, CVS repositories, etc., it is not surprising to find that the information found is outdated.

This article begins to develop a solution to meet the need to keep software project information up-to-date: A glossary that can be used to exchange project details on the WEB for XML documents. In the 1th part, I'll list the scope of the project, choose the implementation technology, and review the relevant work in hand.

Goals, scope and strategy

A name is required for each project. I was inspired by FOAF, a friend of mine, who decided to name the project DOAP, the abbreviation for "Project description (Description a project)". Now the most difficult choice 90% has been completed, the rest also have the prospect!

Projects like this can easily get out of control and produce the opposite result. If you create something that is more or less fulfilling than your current actual requirements, you are unlikely to succeed, no matter how much benefit your XML vocabulary can bring. The WEB is littered with projects that have failed because of too much to do. It is worthwhile to limit yourself to a smaller set of goals that are more realistic.

The limited requirements in the first iteration of this glossary include:

International description of software projects and their associated resources, including contributors and WEB resources

Basic tools for creating and consuming this description easily

Interoperability with other popular WEB metadata projects (RSS, FOAF, Dublin Core)

Ability to extend glossaries for specific purposes

The first iteration explicitly does not contain a description of the software version. This work can be studied later in the iterative process. In addition, planning data within the project, such as task assignments or milestones, are not considered within the scope. You don't have to go too far to reinvent the Microsoft project!

The use cases described in the project include:

Simplicity of the project import software directory

Data exchange between software catalogs

Share automatic configuration of resources such as CVS repository or bug tracker

Package maintainers that help bundle the software to be released

Technology options

Despite years of vocabulary development, the choice of technology remains an open issue. A wide variety of popular vocabularies are deployed in different ways to prescribe their terminology. Study some of these to see if you can get good experiences or useful lessons. For links to all these specifications, see resources.

Dublin Core Metadata element Set: This popular library metadata application uses a technology-independent representation that demonstrates how elements are represented in Rdf/xml, HTML meta tags, and the XML Schema of the consortium through accompanying specifications. Dublin Core was very successful, but there were some ambiguities in the interpretation of the terminology, creating some interoperability problems. For example, the Creator is defined as "the entity primarily responsible for the production of resource content." Examples of Creator include people, organizations, or services. Usually the name of the Creator should be used to identify the entity. From a computational standpoint, the term "name" may have a very broad interpretation, and the definition is actually valid only for the human consumer of the meta data. It is not clear, for example, whether it is a person or group of people who create entities.

RSS (RDF Site summary/really Simple Syndication): Multiple versions of the specification have chosen different routes: version 0.91 uses an XML DTD plus a, a description of the RDF schema, and 2.0 uses With examples of the ping-a-Syria. Sub-standardization has always been a question of RSS interoperability.

EbXML: The glossary from this E-commerce project usually uses a large number of classifications in their formal specifications, as well as examples, DTDs, and schemas.

HTML: is very successful by any standard measure, and HTML is largely extended with the support of specific examples. Now it has a more formal specification, but it's too late. It took many years to clean up the work. Poor interoperability is a huge cost, and time is wasted on testing a Web site with multiple browsers, actually supporting the legacy features of the browser itself.

Since DOAP's main consumer object is a computer, the vocabulary clearly requires some kind of machine-readable pattern. On the other hand, this issue is equally important because data is created by people, providing enough human-readable information to avoid the interoperability of the sub-normative. A clear goal of DOAP is to exchange vocabularies, so that data loss due to inconsistent terminology usage should be minimized. If you've ever tried to sync vCard data between devices, you know that while the data is on the surface, each implementation has its own quirks to solve.