Hi Jeff
OK the current daily build is back to normal with the same behaviour it had
before - sorry for the confusion.
There is also now a helper method on Element
public QName getQName(String qualifiedName);
which makes it easy to do properly namespace-aware element or attribute name
comparisons. As mentioned in the previous mail, the following are now
possible:-
// find all elements with a local name of "foo"
// in any namespace
List list = element.elements( "foo" );
// find all elements with a local name "foo"
// and the default namespace URI
List list = element.elements( element.getQName( "foo" ) );
// find all elements which match the local name "foo"
// and the namespace URI mapped to the "x" prefix
List list = element.elements( element.getQName( "x:foo" ) );
James
----- Original Message -----
From: "James Strachan" <[EMAIL PROTECTED]>
To: "Jeff Turpin" <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Thursday, August 16, 2001 10:13 AM
Subject: Re: [dom4j-dev] Changed behavior in element(String name) method
> Hi Jeff
>
> Sorry to spring that one on you - I meant to send an email describing the
> experimental change to see what people thought.
> I tried to document it in the patches section on the website
> http://dom4j.org/todo.html
>
> The quick answer is I'm going to change the code back again.
>
> Now the longer answer over why I made the change...
>
> My general thinking was, in documents without namespaces (or only using a
> default namespace)
>
> <foo xmlns="whatever">
> <bar/>
> </foo>
>
> then the change to use qualified name rather than local name wouldn't make
> any difference. Searching for name "foo" and "bar" would find the required
> elements.
>
> If however we were reading a document which uses namespace prefixes such
as
> an XSL stylesheet and we wanted to find a <xsl:template> element,
comparing
> only on the local name is kinda risky as we could find a <template>
element
> by mistake. (Or a <x:template> or whatever).
> So I thought it might be cleaner, if you know what prefixes are being used
> in a document that it might be more useful to search by qualified name. So
> searching for "xsd:template" would match <xsl:template> but not
<template>.
>
> This is fine if you know what the prefixes were that were used. You could
> argue that the prefixes are irrelevant and that you should, just like
XPath
> does, ignore what the prefixes are and just compare local name and
namespace
> URI. (i.e. only compare the URI that the prefix maps to)
>
> So if you want to ignore prefixes, just compare local name and namespace
URI
> you can use the QName approach. I tend to do this by defining literals:-
>
> e.g. if we had a document like this:-
>
> <x:foo xmlns:x="http://www.x.com/x/1.0";>
> <x:foo id='123'/>
> <x:bar name="James"/>
> </x:foo>
>
> or this
>
> <foo xmlns="http://www.x.com/x/1.0";>
> <foo id='123'/>
> <bar name="James"/>
> </foo>
>
> the following code would work, and wouldn't find any elements 'by mistake'
> which are in the wrong namespace.
>
> import org.dom4j.Element;
> import org.dom4j.Namespace;
> import org.dom4j.QName;
>
> public class Foo {
>
> public static final Namespace NAMESPACE = Namespace.get( "x",
> "http://www.x.com/x/1.0"; );
>
> public static final QName FOO = QName.get( "foo", NAMESPACE );
> public static final QName BAR = QName.get( "bar", NAMESPACE );
>
> public void doSomething( Element root ) {
> Element foo = root.element( FOO );
> Element bar = root.element( BAR );
> ...
> }
> }
>
> You can use the QName literals as if they were Strings "foo" and "bar"
> except they properly compare element (and attribute) names, via only local
> name and namespace URI.
>
>
> So to cut a long story short, I've now convinced myself again that we
should
> have 2 ways of comparing element names - using local name only (as the
code
> was until I patched it yesterday) and by comparing QNames (local name and
> namespace URI).
>
> What I will do though is add a helper method to Element to make it easier
to
> get a QName for a qualified name. e.g.
>
> // find all elements with a local name of "foo"
> // in any namespace
> List list = element.elements( "foo" );
>
> // find all elements with a local name "foo" and the default namespace
> URI
> List list = element.elements( element.getQName( "foo" ) );
>
> // find all elements which match the local name "foo" and the
namespace
> URI mapped to the "x" prefix
> List list = element.elements( element.getQName( "x:foo" ) );
>
>
> I'll patch the code to implement the above and mail when its available.
>
> James
> ----- Original Message -----
> From: "Jeff Turpin" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Wednesday, August 15, 2001 10:38 PM
> Subject: [dom4j-dev] Changed behavior in element(String name) method
>
>
> I have noticed that in the latest 0.9 patch release which I downloaded
> today to correct the SAX validating parser problem, the implementation
> of the element(String name) method has changed in the DefaultElement
> class. In the previous 0.9 release the method called the getName()
> method which returned the local name. According to the javadoc
> description of the method("Returns the first element for the given local
> name and any namespace") this makes sense. However in the patch release
> the getQualifiedName() method is now being called. Is this the intended
> functionality? Is this a permanent change? If so I will need to change
> quite a bit of code. Cheers!
>
> _______________________________________________
> dom4j-dev mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/dom4j-dev
>
>
>
>
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
>
>
> _______________________________________________
> dom4j-dev mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/dom4j-dev
>
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
_______________________________________________
dom4j-dev mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/dom4j-dev
