Re: SA-ML anyone?

On 29/7/2002 16:49, Will Partain wrote:

> For my part, I've been more inclined to keep the object
> model and ditch all the XML-ism :-)

Heh, I must have been reading your mind and decided to go the other way out
of contrariness ;-)

> Some concerns with your XSLT (courtesy of Phil Wadler,
> surprise) line are:

[Heck, what's he up to these days?]

> (a) Grokkability by Real Sysadmins (TM) [...]

Grokkability is probably my prime concern about Arusha at the moment. I'm
worried that understanding what's happening in sidai requires taking apart a
whole heap of inter-dependant config files and sections of the core engine.

My related concern is that we've tangled up the information with the
mechanism. There's a very blurry line between "how is PHP configured at this
site" and "how did we configure PHP at this site". They seem almost the
same, and Arusha/sidai tends to treat them the same, but I'd like to be able
to view them differently.

To explain what I mean by this, consider the whole 'configure_args',
'extra_configure_args', 'ldflags', 'dep_lflags', 'proxy-host:LDFLAGS', etc.
madness. I've tripped over this a few times in the last couple of days
trying to get (surprise) PHP+extensions configured. I didn't sufficiently
understand how all these relate to each other and managed to disable
important behaviour and mess up the first few builds.

Somehow I wanted to be able to say "PHP is configured with the following
options and uses the following libraries" without having to worry overly
about how that will be achieved.

The current solution is "add some more parameters", but perhaps an
alternative solution would be "add some more syntax". This is sort of based
on the idea of Lisp macro programming, but using XSLT. When the information
starts getting tangled with the mechanism, we could just add a new
schema/namespace that abstracts out the information and push the mechanism
into an XSLT transformer.

God knows XSLT isn't pretty, but you'd only need to write it when you're
changing, or implementing new, mechanism.

> (b) Doing better with "constraints" [...]

I don't know. So far I'm pretty happy with constraints, so I'm not sure how
to do better ;-) But then I have a relatively simple setup at the moment.
What things are bugging you Will?

> (c) The CERN people have done a configuration language with
> type checking [...]

Well, a thought that sprung to mind is that with proper schemas we could use
a validating parser. Not much in the way of type-checking, but a start ;-)

> (d) There's another LISA paper about using the Zope-like
> idea of "acquisition" in a configuration language [...]

Hmmm... is any of this getting closer to something that the average syadmin
would use?

My thought about moving back more towards "runnable" documentation comes
from a demonstration that Norman (Glasgow Uni SA) gave to me a few years
ago. He had written a bunch of crib sheet web pages explaining how to do
various common tasks in maintaining the NT labs. But he'd written the web
pages such that they had magic MS links that allowed you to click on a link
and have it actually do the task, or at least open the program that you
needed to do the task.

I reckon by now that most syadmin types can edit a web page, and thus should
be able to handle using XML as a markup language. But at the moment we use
it really as a data pickling format. The config files don't actually read as
documents, and writing one isn't like writing down a crib sheet.

But what if it could be? What if you could do something like:

  <section id="configure">

  We configure PHP with the <args>--enable-xslt</args> option
  in order to get the XSLT extension. We use
  <dependency id="sablotron--0.95">Sablotron</dependency> for
  the actual XSLT engine, which requires adding the argument
  <args>--with-xslt-sablot=<deploy-dir id="sablotron--0.95"/></args>.
  We add the optional <args>--with-sablot-js</args> argument to get
  the EXSLT JavaScript extensions.

  </section>

This is pretty pie-in-the-sky stuff, but you can see that most of the
information necessary to actually configure PHP is specified in the tagged
parts of this section. Writing an XSLT transformer to turn this into
something more executable wouldn't be too hard.

As always, I'm not wedded to these ideas yet ;-) So any and all feedback
would be welcome.

I'm in the middle of a (you guessed it) XML/XSLT document project at the
moment, but when I get out from under this I'll try playing with some of
these ideas so I can show you some demonstrations.

Jonathan

-- 
jonathan hogg, one good idea ltd, 131 queen margaret dr., glasgow g20 8pd
http://www.onegoodidea.com/ tel:+44-(0)7976-614338 fax:+44-(0)7970-537451