commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rahul Akolkar <rahul.akol...@gmail.com>
Subject Re: [chain] DTD/XSD of config-chain.xml
Date Mon, 19 Dec 2005 16:55:03 GMT
On 12/18/05, Wendy Smoak <wsmoak@gmail.com> wrote:
<snip/>
>
> Any thoughts on the use of <catalog> as the root element vs. <chains>
> as shown in the cookbook examples?
>
> Using <catalog> puts the commands into the default catalog which is
> retrieved with CatalogFactory.getInstance().getCatalog().
>
> Using <chains> seems to do something else.  I haven't figured out if
> the commands are going somewhere else, if the config file just isn't
> being parsed, (or if I'm imagining it.)
<snap/>

As Craig mentions, its in fact better to have <catalogs> (or <foo>,
but thats not readable) as the root since that allows placing more
than one <catalog> elements in the chain config. Sorry, I'm not sure
what <chains> is all about, I'll have to take one more look at the
cookbook later. But looking at the trunk I can tell you the only
elements of any semantic significance are <catalog>, <chain>,
<command> and <define> (by default, though <define> could add others
-- and it might even be possible to redefine <command>, which I
believe is part of the "insanity" that was refered to ;-).

The absence of a DTD and validating digester can indeed cause "silent
failures" where the *intent* of the author goes unnoticed.

Going back to the question asked, is there anything that can be done
to help WRT validation at authoring time for chain configs, short of
having users understand the digester? What do folks think about
providing a DTD for the defaults, maybe on the wiki? This can provide
some "in-editor" validation for the default rule-set, and a user may
enhance the DTD for their own custom rules if they see fit (while the
digester will continue to not be validating).

-Rahul


> Thanks,
> --
> Wendy
>

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org


Mime
View raw message