Re: SA-ML anyone? (oh so very long)

Jonathan, thanks for a super-interesting read; I'm not yet
in a position to comment sensibly (and am off on holiday in
a week's time...), but thought I would go ahead and toss in
a few mumblings of my own.

> So having argued in the past for rationalising and extending the Arusha
> object model, I'm now arguing for throwing it away entirely ;-)

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

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

(a) Grokkability by Real Sysadmins (TM) -- I have a constant
worry about "this stuff is too hairy, and no-one will touch
it" re ARK things.  I am pleased with the (relative)
simplicity of the present ARK stuff, but it is far from
clear if that's good enough.  XSLT might push us way over
the edge.

(b) Doing better with "constraints" (as we now call them)
[or dependencies]:  My hunch has been that if ARK <n+1> is
going to be qualitatively better than now, it will be
because of a better story on constraints.  Would XSchema/etc
stuff make it easier to get that "better story"?

(c) The CERN people have done a configuration language with
type checking (PAN; they have a LISA paper on it this
year).  We could always go wild and show them how it's done
correctly :-)

(d) There's another LISA paper about using the Zope-like
idea of "acquisition" in a configuration language; so,
instead of a host 'A' having a prototype 'lab-host' from
which it inherits a subnet mask, the 'lab' object *contains*
host 'A', and all host 'A' knows is that it *acquires* its
subnet mask from its containers.

So many ideas bubbling, so little time...

Will


-------------------------------------------------------
This sf.net email is sponsored by: Dice - The leading online job board
for high-tech professionals. Search and apply for tech jobs today!
http://seeker.dice.com/seeker.epl?rel_code=31