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

[Bruce Sass]

"Steve Horne" <sh at ttsoftware.co.uk> wrote:
```
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).
```

On Sun, 29 Jul 2001, Peter Hansen wrote:
> Dirck Blaskey wrote:
> > Unless you have compelling reasons for using XML, I would suggest
> > the alternative of using Python itself as the meta-language.
<...>
> > 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.
<...messed with the order...>
> 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.

That is correct: XML is perfect for this kind of thing, but the
dependency on a specific set of tools, because it is not "easy on the
eyes", makes it unsuitable as the _only_ source format for something
like this (which tends to get frequent inspection by sets of eyes).


> 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.

Ya, requiring separate files would be a mistake though.

> 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.

I've been playing around with this stuff a bit (LP view)...
Using LP techniques you end up putting all the meta information in
"program" chunks, and have part of your build procedure collect
whatever data it needs from them (via naming conventions).  Generating
XML could be easy, because (noweb notation) "<<label>>=\n...\n@" is
the same as "<label>...</label>".

The thing is...

<<label>>=
  <<referred-to-label>>
@

...is not the same as...

<label><referred-to-label></referred-to-label></label>

...and I'm not sure of the relationship between them.

At first glance I'm inclined to think that XML is too low level a view
for everyday use, and that anything in XML can be represented with LP
(after all, on some level, XML is just blobs of text in a file, LP
just takes those blobs and surrounds them with documentation).

My main concern when I hear, `lets's use XML', at the start of a
project... Is there any danger in defining something in terms of a
DTD, as opposed to generating a DTD from an abstract definition?

I suppose an analogy could be draw between this situation and doing
web pages... would doing a programming project in terms of an XML DTD
be the same mistake as doing your web project's pages in straight
(X)HTML?


> 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).

I hope your prediction is accurate.

When I first started thinking about this subject (the whole
project-in-a-document idea, as I see it) I considered starting with
defining a "project", then using tools to work with the definition...
but found it was easier to create a view of the project at the lowest
level of representation I wanted (plain text) and use existing tools
as much as possible to do the pretty printing and

	text based source file  <--->  installed software package

conversion.  I've gone as far as ...file --> working software
(stopped short of packaging it, for hack vs. do it right, reasons)
using LyX[1] with noweb[2] and a coded build procedure[3].

The code is bash, but could just as well have been make based, and I
would probably really do it in Python[4], or some combination of
techniques.

I guess what I'm beating around the bush about is that XML should be
seen as just one view of a "project", and the main view should be
based on something easily translatable to and from other common
representations (XML?)  e.g., I adopted a file based view from the
perspective of a source package; the LP tools provide a split between
the documentation/code and translation to/from files, custom tools are
needed to make sense of the translation, standard tools can be used to
manipulate the files (build, etc.).

anyways, that's my view.


<aside>
If only LyX's Scrap environment could do syntax highlighting,
and provided more than just "build" and "print" functions...

Xemacs + LyX anyone?
</aside>


- Bruce

[1] http://www.lyx.org/
[2] http://www.eecs.harvard.edu/~nr/noweb/
[3] http://home.edmc.net/~bsass/mkfd.lyx
[4] ...just as suggested by Dirck Blaskey.  I like the look of literal
dicts, lists, etc. better than XML; and using dicts with LP is a
natural.