I have come up with a first specification of OsXml, an XML schema for publishing and distributing Open-Source code.
There is no standardized way of publishing open-source code. It can be easy to find a snippet of code online, but without key information, such as the license, authorship, known bugs, etc, it is virtually useless.
I have come up with a rough first draft of an XML schema which is designed to help people share, and ultimately find and use, open-source code. The first draft is available online at OsXml.org.
Constructive criticism on how I can make it a better format such as what information would be useful to introduce (or omit) from the schema would be much appreciated!
Why publishing open-source _code_ only ? What about documentation ?
I think OsXml could (and should) follows the literate programming paradigm. Documentation is indeed more suitable than code to share ideas and concepts with the Open Source Community.
For me, a project should be a literate program with hypertext links to references, sources codes pieces (whatever the language used), file's history, etc. I hope for a file format allowing human to easily browse such a program with an 'aspect oriented reading'. This format should therefore be easily read and modified by a simple folding-featured text editor with for example: - 'code fold' to focus on code - 'API fold' to focus on API documentation - 'history fold' to explore files by versions - etc.
We could even imagine using a web browser to develop program with an interface like Zope...
Don't you think OsXml could includes such information ?
I assume that non-open-source projects are not interested in publishing open-source code. An open-source project mixed with non-open-source code, make the project non-open-source, and the whole thing becomes a mess of partially usage text.
> What about documentation ?
I think the documentation is crucial and should be included as part of the document. Documentation and source are more or less the same thing, AFAIC.
> I think OsXml could (and should) follows the literate > programming paradigm.