Another possibilty would be to let the user choose. Suppose that
config.getPropertyValueAsString("name") -- a bit of a long name -- returned
"Something" for both of the following
<component name="Something" />
and
<component>
<name>Something</name>
</component>
And threw a ConfigurationException in the case
<component name="Something">
<name>Something else</name>
</component>
It would mean a noticable change to the way DefaultConfiguration works, but
I don't think people tend to design configuration files that would cause
problems with the third case. It would still be good to have a standard
format that comes with releases, but certainly the user could change things
around if it was desirable.
David Weitzman
Peter Donal wrote:
> On Mon, 9 Sep 2002 00:24, Leo Sutic wrote:
> > In short: Peter - just do what feels right. This is like the whitespace
> > style of your code (brace on same or following line?), and we can expend
> > a metric shitload of time arguing back and forth with very little of
> > actual value coming out of it.
>
> ahh - okay ;)
>
> I am using Davids suggestion and it seems to work reasonably well. In
database
> terms it boils down to;
> * normalize data
> * keys (or candidate keys) become attributes
> * repeating groups become elements
> * remaining data items become either elements (if long), attributes (if
> "salient") or I flip a coin if no other rule holds ;)
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
