metadata about sources(was Re: Defense)

A nearby topic and the common denominator of this thread is that "agents" w=
alk =

the sources and try do clever things with it. One can for the sake of this =

discussion assume a future development of that arbitrary agents with =

different purposes walk the sources, and they all need metadata about the =

sources.

Currently we have building(compilation) which relies on Makefile.amS for in=
fo =

about what to do, and there's the experimental Defense that currently needs =

no extra metadata, but could do very interesting things if it had. So, =

currently there's metadata in Makefile.amS, and there's some type of metada=
ta =

in the SVN repository.

What I think would be useful is to store metadata in a generic way. That =

instead of Makefile.amS, one had an XML format that was typed in W3C XML =

Schema which allowed extensions from different namespaces to be dropped =

in("modules"), and hence not tie a file to one thing but store it generical=
ly =

such as the info could be used for different needs. For example, one could =

have a namespace extension for:

* contact information(yes, I know about the problems with that that was =

discussed), perhaps by pulling in the appropriate elements from Docbook 5.0
(it's in a namespace)
* Generic documentation, "what is this app?", which we already have in INDE=
X =

files, for example
* Build info for autobreak and similar(what's found in Makefile.am, in =

principle)
* TODO/Roadmap(that is, it's stored in a structured way, and nearby the =

sources)
* Metadata for, say, Defense. To disable certain tests for that dir or =

particular files(although I'm relucant to that for other principles).

And with info one can do clever operations upon. For example:

* since the XML is strongly typed, one can validate the files, and detect =

build errors at commit time or with defense("No, that library does not =

exist").
* And since the information is stored centrally in an object oriented way(n=
ot =

for a specific purpose, which it for example is on a hand coded website) an=
d =

structurally, one could generate, say, an application overview simple as a =

piece of cake
* Doing mass-edits of those XML files is also a piece of cake(XSLT)

The idea is too experimental and the demand currently too low, but if one =

works on and deploys something like Defense it wouldn't surprise me if it =

became more realistic. It would also require adapting tools to interpret th=
e =

XML(such as build system) but with large changes such as the switch to bksy=
s =

etc, it's not completely of the chart.

(On the topic of storing contact info. Imagine such an initial deployment o=
f =

XML metadata files was done programatically, and that contained contact =

information was added by simple statistic measure on the files(who have don=
e =

the most commits in these files, according to SVN?). On a weekly basis erro=
rs =

found by Defense was sent out in mail, as according to the contact =

information. If that contact information is wrong(which it periodically wil=
l =

be over time), I think people would be quick to patch it.)


Cheers,

Frans

=
[color=blue][color=green]
>> Visit [url]http://mail.kde.org/mailman/listinfo/kde-devel#unsub[/url] to unsubscrib=[/color][/color]
e <<