xml-dev - Re: Configuration files

[Peter Murray-Rust <peter@ursus.demon.co.uk>]

At 10:32 26/06/98 -0400, Eddie Sheffield wrote:
>Hi all,
>
>I don't know much about XML, so I've just been lurking on the list. But

Welcome! Most of us (certainly me) started by lurking and occasionally
asking questions. 

>I do know Java, so maybe I can finally contribute something worthwhile
>here! ;-)
>
Excellent.

>Michael Kay wrote:
>> 
[...]
>
>Have you looked into using resource bundles? While these are often used
>for internationalization, they can be used for many other things as
>well. They're closely related to the Property objects, so you're on the
>right track. The nice thing about ResourceBundles is that they are
>located by the class loader, so they come from the same place your
>classes come from, regardless. They're simple to use, too. You simply
>name the configuration file(s) filename.properties and then use a static
>method on ResourceBundle to retrieve the filename resource bundle. From
>this you can ask for specific properties much like a Properties object.
>So for example you might have the following file and contents:
>
>saxon.properties
>----------------
>saxon.preferredbrowser=msxml.class

This is exactly the mechanism We want. I had noticed resource bundles and
wondered about them but - as you say - the examples were primarily
concerned with i18n.

[...]
>
>> As far as I can see it is possible, but deprecated, to read
>> environment variables from java. An environment variable to
>> define the parser (or the configuration file in which the
>> parser is named) would be the obvious and traditional
>> solution.
>
>As an aside, this is correct. No environment variables. And the reason
>given is that not all systems (like the Mac) support environment
>variables. But this seems like a pretty lame excuse to me. There are a
>number of Java "system" variables that are available. Looks like the JVM
>could simply append the list of whatever environment variables exist to
>this list. Some systems would have many, some few, some none. But at
>least they would be available.

Yes. My first JUMBO (under 1.02) was able to get envs since Java allowed
this (can't remember the syntax). Then, in JDK1.1 they didn't just
deprecate it, they took it away :-)

It's perhaps worth thinking about the things that we would want to bundle.
My list - so far - is:
	- icons
	- documentation (often on a per-element basis)
	- menus driven by declarative programming (e.g. <checkbox status="on"
value="uppercase"/>
	- lists of resources (e.g. classes of parsers)
	- other primitives to drive the operation (e.g. pre-loaded options)
	- display configurations (cf. XWindows)
	- MIME types
	- glossaries 
	- screen configuration 
	- legacy data information
	- entity sets
	- DTDs
	
and so on. Anything that one might find in a *.ini file. but, of course,
everything in XML.

It would be extremely useful if we could agree some conventions. Thus I'd
like to write:
<PARSER NAME="AElfred">com.microstar.xml.SAXDriver</PARSER>
<PARSER NAME="XP">com.jclark.xml.sax.Driver</PARSER>
...
Essentially these could then be in a flexible order in the config file
(since we can use XPointer to navigate them). It makes updating very easy.
We just have to agree on a few conventions.

Comments welcome.

	P.


Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic
net connection
VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary
http://www.venus.co.uk/vhg

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)