Stefan Heimann wrote:
> On Tue, Sep 03, 2002 at 05:13:25PM +0200,();
>>
>> }
>
>
> What about namespaces in a pattern? There must be a way to register
> the uri-prefix mapping.
I had such methods in the interface at the beginning...
However I think that both SimpleMatcher (currently RulesBase) and
ExtendedMatcher (currently ExtendedBaseRules) should not have the
namespace prefix matching support built-in, simply because not many
people need it, and it adds a lot of overhead (i.e. having to deal with
a stack of local names and namespace URIs, or a QNameList as in your
patch). Neither would they directly support any of the other matching
features I listed in my proposal. That would be left for special matchers.
So, if we add something like a NamespaceAwareMatcher (stupid name, just
an example ;-)), you could have the namespace-prefix-registering methods
directly in that class. The API client would have to use the class
directly anyway, as in:
NamespaceAwareMatcher matcher = new NamespaceAwareMatcher();
matcher.addNamespace("foo", "");
digester.setMatcher(matcher);
Having the method(s) in the base interface will probably just confuse users.
>.
>
> I would suggest not to support such a namespaceURI argument. Instead,
> we could provide a setDefaultNamespaceURI. If the default namespace
> uri is not null, all elements in a pattern will be treated as
> contained in that namespace.
Hmm... but the namespaceURI argument in Rules.match() is used to exclude
rules that don't match the current namespace, or if (namespaceURI ==
null) to include all rules. This is to support the namespace specific
rule(set)s. I don't see what that has to do with defining a default
namespace.
--
Christopher Lenz
/=/ cmlenz at gmx.de
--
To unsubscribe, e-mail: <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>