XML for meta-information (was Re: Deposing Dictators)

[Stephen Horne]

On Sun, 29 Jul 2001 00:38:01 -0400, Peter Hansen <peter at engcorp.com>
wrote:

>Dirck Blaskey wrote:
>> 
>> "Steve Horne" <sh at ttsoftware.co.uk> wrote:
>> > ...
>> > 1.  A lot of the ideas turn out not to be for a programming language
>> > as such at all. Rather, it combines the ideas of literate programming
>> > with a kind of replacement for make. An XML notation would allow
>> > source code in a range of languages to be packaged in a linked set of
>> > XML files with documentation, detailed specification of the build
>> > process and explicit requirements for the run-time and build-time
>> > environment. It would allow you to specify, for instance, that the
>> > source code for this C++ module contains a constant structure derived
>> > according to xxx principles (for the documentation) and can be
>> > generated by running yyy script in zzz version of Python (or
>> > whatever).
>> 
>> Unless you have compelling reasons for using XML, I would suggest
>> the alternative of using Python itself as the meta-language.
>
>I think there are always compelling reasons for using XML.  XML 
>is not code -- it's data.  Python is for expressing algorithms
>'n such.  XML is perfect (well, maybe not quite) for meta-
>information, or at least as perfect as we've come up with to date.

My thoughts exactly. XML is not designed to be human-friendly, it is
only designed to be human-readable as a last resort.

>I like Steve's idea above, although it sounds like it might
>be a little "monolithic" if one didn't take care to keep the
>pieces separate.  Of course with XLink there's no reason the
>pieces of information relating to a single module all have
>to be in the same physical file.  

The root element in most files would be <component>, I think, though
there would be a file with root element <project>, some files with
root elements such as <tool> (to describe compilers, interpreters,
linkers and other tools, and how to call them) and possibly several
others.

I haven't looked into XLink yet, but certainly some kind of
link-following mechanism would be present. In fact, I expect that
'#include', 'import' and similar lines would generally be generated
automatically using tool-derived cross-reference information. The need
for include guards could be removed from C and C++ components - you
would know absolutely that precisely the declarations you have
declared an interest in are understood by your code with no chance of
double-inclusion.

I want pieces to be kept separate, but the division should be based on
the components - not on whether the file contains documentation,
source code, build instructions, test cases or whatever. Information
related to the same component should be kept in the same file, and it
should be the tools job to cross-reference and correlate the
information required to generate documents, executables or whatever.