Lists Home |
Date Index |
- From: Peter Murray-Rust <email@example.com>
- To: firstname.lastname@example.org
- Date: Fri, 26 Jun 1998 16:50:37
At 10:32 26/06/98 -0400, Eddie Sheffield wrote:
>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
>I do know Java, so maybe I can finally contribute something worthwhile
>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:
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
>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:
- documentation (often on a per-element basis)
- menus driven by declarative programming (e.g. <checkbox status="on"
- 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
- screen configuration
- legacy data information
- entity sets
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:
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.
Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic
VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary
xml-dev: A list for W3C XML Developers. To post, mailto:email@example.com
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:firstname.lastname@example.org the following message;
To subscribe to the digests, mailto:email@example.com the following message;
List coordinator, Henry Rzepa (mailto:firstname.lastname@example.org)