Re: [Xmlunit-general] XPath and Namespaces in 1.1 beta

[Stefan B. <bo...@ap...>]

On Fri, 20 Apr 2007, David Carver <dc...@st...> wrote:

> There has to be a simplier way to get the namespaces to work.

Maybe.  The most important thing is that it works, though.

> My own custom modfications uses the apache XPathAPI interface, that
> resolves space for you.

We can't go that route, we really need to be parser independent.

> The JAXP 1.3 NamespaceContext is almost a kludge.  While I know it
> allows for parser independant implementations, it also requires you
> to know the namespaces ahead of time.

The URI, and then you can use whichever prefix you want.  What would
be the usecase for XMLUnit where I don't know the Namespace at all but
want to validate an XPath expression that uses the Namespace?

> I figure XMLUnit should at least if you specify that you want to use
> namespaces, that it automatically pulls from the DOM the namespaces
> that have been defined and the prefixes defined in the XML document.

The I'd need to know the prefixes when I specify my XPath expression,
or not?

> As it is now, unless I'm missing something, the XMLAssert static
> functions still aren't namespace aware, because they directly
> instantiate the newXpathEngine() method, which doesn't set a
> NamespaceContext when it is created.

It does, if the context has been set via XMLUnit:

    public static XpathEngine newXpathEngine() {
        ... pick the best available implementation ...
        if (namespaceContext != null) {
            eng.setNamespaceContext(namespaceContext);
        }
        return eng;
    }

> Also, there should be a way for the engine to be established once,
> and reused, instead of being created each time.

I thought about that, but the way it is implemented is consistent with
the handling of parsers and transformers.  You get new instances of
them when you use XMLAssert as well.

If you want to reuse instances you can do so by not using XMLAssert at
all ...

> A few of these enhancements would go a long way to help improve
> useability of the framework.

Hmm, could you please explain how it would do so?  How would your
envisioned API usage look like?

Thanks

        Stefan