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

[Peter Hansen]

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.

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.  

I've been thinking for a while (as I'm sure many have) that the
current use of simple text files for source code is remarkably 
primitive compared to the overall state of computing.  It seems
like it's time to turn things "inside out", and put source inside
XML files as merely one part of the picture.  Build instructions
for "make" or "pyscons" tools would be kept inside.  Specifications,
test cases, etc, would also be available in nicely organized
packaging.

Now we have only text editors, which grab an entire file and 
present a simplistic line-oriented view of it, possibly knowing 
enough about the content (as described by the file extension: 
how primitive!) to do something useful with it other than just 
display it.

In the future, structured editors would be able to work not
only with the source content, but other kinds of information
contained in the same file.  If they didn't understand the 
information, they would ignore but preserve it (as XML tools
should do).  

Sort of reminds me of Opendoc... but built around a modern
web-standard and inherently more suitable to the kinds of 
work programmers need to do.

> Maybe I don't fully understand your intended use of XML, but
> it gives me a good opportunity to go off on a tangent, as well.
> (Hmm...  Maybe it's time to change the subject: line?)

Done. (You don't have to ask, either. :-)

> XML is a bit hard on the eyes (quite unlike Python).

Well, that might be more a condemnation of the tool being used
to view the XML than of XML itself.  XML, while designed to be
easy to edit in text editors, was not designed specifically to
be "easy on the eyes".  The designers would likely have said that
it is not XML's job to specify a presentation format for itself.
XML is content, end of story.

-- 
----------------------
Peter Hansen, P.Eng.
peter at engcorp.com