Re: [Config4gnu-developer] XML specification (1st draft)

[Peter W. <wie...@we...>]

Hi!

Justin wrote:
>[...]
> should be.  Once it is stabilized, we'll publish a 1.0 XML spec and
> detail which is necessary to be compliant w/ the spec.  If you have
> any suggestions, or are working on any other type of specifications
> for these sorts of things, we'd love to compare notes.  If you want
> to help us define the exact spec, we'd be open to that as well.
>
What I'm thinking of is a separation between the syntax and the
semantics =3D the naming order.
If you convert to/from linuxconf, there alerady is a point of
cross-software order. And you should document and develop
syntax and semantics separated from each other (if you're not
already donig so), at lest IMHO.

> I've looked over your website and I noticed you mentioned a few
> things about CFG [...]
> [...].  I'll try to clear up some things, not that I think
> you're totally off-base, but I suspect there may be places we are
> unclear:
>
> Your mention that we want to be an abstract UI is 100% correct, we
Yes CFG is an UI between sys administrator and the distro specific
scripts and tools.
But when I write about abstract UI what "spooks" through my mind is an
abstract UI ***for*** CFG and linuxconf and ...
Because my confcoord project just started, the documentation files
"explode" (the become biger and more very fast). Later this speed
will drop.
I will soon present my software "AUI". It sucks a bit :) but it shows
my ideas. The console implementation already works, now comes the xlib
implem.

> As far as our XML format, no one using the final product of our
> project should need to understand XML at all.  Programmers using it
> will need to understand how to retrieve data from XML, which is
> very easy in most languages.  Using the XML won't be required, as
> the native config files are still the authoritative version, so
> things won't *need* to be re-written to allow CFG to configure
> them.
I extended the comment "complicated" about XML because I think
there are some sort of XML parsing libs or so.
In the chapter "conf languages" I think of programmers who write
the equivalent of your main engine and/or conf data scripts (but for
the middle layer and for many sys conf areas).

> structures.  Right now we use our own basic parsers, and part of
> the process of adopting libconf would be getting their parsers to
> understand XML and/or writing a translator between their perl
> structures and XML (which we've done to an extent).
That is exactly the sort of project I would like to see.
I'll try for example to write documentations that could help.

> If you are interested in helping out with or joining our project,
> we would welcome any contributions you have.[...]
What I've seen so far CFG has the best (the only!) design for conf
standardization.
But there are still a lot of parallel/isolated developments in other
projects, that keep me busy!
Currently I think it's better to just stay on your mailing list and
suggest ideas and tell if in rare occasions I manage to produce
some ugly code.

> [...]  If you want to
> maintain your own project, we are interested in there being a
> configuration standard and would be interested in helping to define
> it.
Yupp! I care about such a standard very much, too.
This will take some time (You already guessed that I bet).
But to overcome the extrem fragementation of linux conf software,
I it is an advantage to take it slow and think in long time terms.
Currently I plan helping for such a standard for the naming order
( =3D naming system =3D semantics =3D ontology).
1.) I first want to document existing ones.
2.) Then I want to look if I can sys conf tool projects that want to
support a semantics standard.
3.) In my plan (plans don't always work) my work ends here, because
several people who have lots of experience in designing linux conf
semantics (maybe from linuxconf?) will sit together and create a
linux conf semantics standard project.
There are other things for conf standardization I will work on, of
course.

> Thanks for your interest in our project & sorry it took til now to
> respond.
To me it looked very fast. Please expect much slower responses and
actions from me!

Kind regards
Peter Wiehe