Re: Use of XML for config files

[Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de>]

Darren New <dnew@san.rr.com> wrote:
: Georg Bauhaus wrote:
:> Fine except that you make a decision to limit us to
:> no subsections unless you allow "Section.Subsection"?
: 
: Yes. That makes it simple.

o.K. but I want more than exactely one layer of key hierarchy
in my favourite API.

: But until
: you say what it is you want, we're going to be arguing in circles, so I'm
: not going to say that.

: [not] given the vaguest outline of what you expect your API to look like.

Speaking of trees and XPath gives several clues, doesn't it?
I want to be able to address the following:
- administer groups of related conf data (recursively)
- administer individual conf items
- administer properties of individual conf items
All of this should be explicit.
AFAICS this is present (more or less implicitly) in the
"API requirements" section, and via "Dot" to some extent in Grace.Config_Files.
While we are at it: Thank You very much, Stephen!
Example:
- multilingual settings for item x.y in [sec_a],
  so that, possibly after further abstraction in my application
  (though for simplicity I'd prefer access along one path in a conf tree),
  I can ask something like

    explanation(property(x, "y"), "de_CH")

  where the text of the explanation is written by non-programmers.
  I can now, but my conf keys will look like x.y.de_CH, x.y.fr_FR etc.
  If the API freezes '.' for it's internal key strings, that's fine.
  But I'm slightly worried that these won't make our customers happy
  and that is why I'm glad that Grace.Config_files makes keys internal,
  so our customers don't have to see them.

IN addition, I'd like to be able to "outsource" as much of
configuration creation/modification as I can/must. But there
are some constraints on this. Since our customers are largy
unaware of text editting issues, I want to provide them with a tool
that looks familiar, so when they use it it will provide us with
relatively useful configuration data.
(Some background (things that happen on the job (not just mine)):
We ask for text only files, we get (at best) an
RTF file of the latest MS Word kind.
You ask for a data feed, you get an HTML page where JavaScript
places content from their local data base into an HTML-table.
What is going to happen if I cannot offer customers like these
an application they can use for typing configuration information?
They aren't stupid, they just aren't used to writing text with
"computer syntax".)

:> : So what are you suggesting the XML-based API should look like?
:> It should make no mention of XML, of course :-).
: 
: Stating what it isn't doesn't really answer any questions. 

It should look like an API that is completely unaware of any outside
file format, and it should be able to cover what is proposed on Stephen's
page. In particular,
"12. Data are accessed by a key of type String or Wide_String."
I'm not sure whether this should say that access is from some level
in the hierarchy to some item at that level (24.), or whether I go
to that level using a (path) string key or both in one step.
Any of this will be fine.

:  Having a very explicit file format finalized before anyone
: even decides what the API looks like is kind of silly.

Well, OTOH, file formats do have consequences for what you can reasonably
want to be present in an API don't they?

But I admit that this is likely to have been what I have been focussing
on during this discussion. Which has been helpful in many respects.


-- Georg