You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Steve Loughran <st...@apache.org> on 2006/06/13 12:24:45 UTC
QName in DynamicAttributeNS
I'm now looking at the namespace aware dynamic attribute stuff
The qname parameter for this is built up as follows:
String qName = ("".equals(uri)
? localName : (uri + ":" + localName));
this is not how, say, Qname.toString() presents qnames, which is
{http://example.org}tag
I'd change it, but then I looked at how XmlFragment handled it, which it
does by handing it off to the Dom element
e.setAttributeNS(uri, qName, value);
I dont use classic DOM. but from what the javadocs imply, this appears
wrong. the qname that Element.setAttributeNS() seems to want is a
classic prefix:value tuple, like "xmlns:name" or "ant:example".
So really we should pass down the prefix and localname, as the uri comes
down in the namespace URI param:
String qName = ("".equals(uri)
? localName : (prefix + ":" + localName));
Am I right here? This is not shipping code so we have time to correct
it, but I'd need input from someone who knows Dom intimately enough to
get it right. Me, I use Xom :)
-steve
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: QName in DynamicAttributeNS
Posted by Peter Reilly <pe...@gmail.com>.
The intention of DynamicAttribute.setAttributeNS() was to
support namespaces in attributes - and it does not work!
Peter
On 6/13/06, Dominique Devienne <dd...@gmail.com> wrote:
>
> On 6/13/06, Peter Reilly <pe...@gmail.com> wrote:
> > The prefix for elements (as against attributes) are retained.
> > ProjectHelper2 called UE.setQName(qName) with the
> > name it receives from the sax.
> >
> > Something needs to be done for attributes..
>
> Namespaces are used to avoid name collision, and in Ant to locate the
> right implementation class. That's necessary for top-level tasks, and
> for nested elements in tasks/types having add(Xyx) methods.
>
> Attributes in Ant OTOH, are always "resolved" relative to their
> element. Their can't be any ambiguity ATM for attribute. Ant doesn't
> support namespace'd attribute at all, AFAIK.
>
> Also, remember that attributes don't inherit the namespace of their
> element, and are always in the "" namespace, unless explicitly
> qualified with a prefix. As I write above, Ant doesn't support them
> for introspected class.
>
> Using namespace prefixes is dangerous, because they can change from
> element to element, depending on while namespaces are in scope, and we
> can have different prefixes for the same NS URI, or the same prefix
> for different NS URIs depending on the element (although this is evil,
> XML supports it).
>
> XmlFragment is already not "exact" XML, as all text nodes, even with
> nested element in between them, are merged together. I'm not sure it's
> worth it to be exact XML... --DD
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
Re: QName in DynamicAttributeNS
Posted by Steve Loughran <st...@apache.org>.
Dominique Devienne wrote:
> On 6/13/06, Peter Reilly <pe...@gmail.com> wrote:
>> The prefix for elements (as against attributes) are retained.
>> ProjectHelper2 called UE.setQName(qName) with the
>> name it receives from the sax.
aah. this explains why I had got echoxml to work doing namespaced stuff.
>>
>> Something needs to be done for attributes..
>
> Namespaces are used to avoid name collision, and in Ant to locate the
> right implementation class. That's necessary for top-level tasks, and
> for nested elements in tasks/types having add(Xyx) methods.
>
> Attributes in Ant OTOH, are always "resolved" relative to their
> element. Their can't be any ambiguity ATM for attribute. Ant doesn't
> support namespace'd attribute at all, AFAIK.
oh, it does, sort of. If you have a task to build qnames of all
attributes passed in and print them out, this is what you see
1. ("",attributes) map to simple attributes
<book:ex test="true") calls setAttributeNS("","test",something,"true");
<target name="showDynaTaskBookNamespace" depends="define">
<book:dynatask username="erik" />
<au:assertFalse>
<au:logcontains text="{http://antbook.org/}" />
</au:assertFalse>
<au:assertLogContains text="username" />
</target>
2. stuff in a different namespace comes down with that namespace
<target name="testDynaTaskAntunitNamespace" depends="define">
<book:dynatask au:username="erik" au:hostname="localhost"/>
<au:assertLogContains text="{antlib:org.apache.ant.antunit}hostname" />
<au:assertLogContains text="{antlib:org.apache.ant.antunit}username"/>
</target>
2. ("prefix",attributes) map to simple attributes if the uri of the
parent element==uri of prefix
This holds for matching prefix
<target name="showDynaTaskBookNamespace" depends="define">
<book:dynatask au:username="erik" au:hostname="localhost"/>
<au:assertFalse>
<au:logcontains text="{http://antbook.org/}" />
</au:assertFalse>
<au:assertLogContains text="{antlib:org.apache.ant.antunit}hostname" />
</target>
And for matching URI, different prefix
<target name="testDynaTaskB2Namespace" depends="define">
<book:dynatask b2:username="erik"
xmlns:b2="http://antbook.org/"/>
<au:assertFalse>
<au:logcontains text="{http://antbook.org/}"/>
</au:assertFalse>
</target>
3. Stuff that matches an introspection attribute binds first
<target name="testDynaTaskBookStandardAttribute" depends="define">
<book:dynatask description="unknown" />
<au:assertFalse>
<au:logcontains text="description"/>
</au:assertFalse>
</target>
4. If you have a localname prefix and something in the same namespace as
the container, whatever attribute is reached last seems to win:
<target name="testDynaTaskDuplicates" depends="define">
<book:dynatask book:attr="one" attr="two"/>
<au:assertFalse>
<au:logcontains text="one"/>
</au:assertFalse>
</target>
#4 is a bit problematic as it violates XML's one attribute of a
(uri,localname) tuple per element rule. You could even, maybe, do bad
things to ant tasks that assume their setAttribute call gets made once
per task. The only way to stop it would be to track attributes set on an
element, and bail if a second attempt to set one was made during
introspection.
>
> Also, remember that attributes don't inherit the namespace of their
> element, and are always in the "" namespace, unless explicitly
> qualified with a prefix. As I write above, Ant doesn't support them
> for introspected class.
>
> Using namespace prefixes is dangerous, because they can change from
> element to element, depending on while namespaces are in scope, and we
> can have different prefixes for the same NS URI, or the same prefix
> for different NS URIs depending on the element (although this is evil,
> XML supports it).
it may be evil, but is often needed. It lets you declare stuff in a new
namespace without knowing every single xmlns declaration in ther rest of
the doc, or even that there is another doc.
>
> XmlFragment is already not "exact" XML, as all text nodes, even with
> nested element in between them, are merged together. I'm not sure it's
> worth it to be exact XML... --DD
It doesnt do PIs either. If you really want low level stuff, <echo>CDATA
works, but I'd like xmlns support to be improved, for anything that uses
DynamicAttributeNS, otherwise the method isnt that useful.
-steve
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: QName in DynamicAttributeNS
Posted by Dominique Devienne <dd...@gmail.com>.
On 6/13/06, Peter Reilly <pe...@gmail.com> wrote:
> The prefix for elements (as against attributes) are retained.
> ProjectHelper2 called UE.setQName(qName) with the
> name it receives from the sax.
>
> Something needs to be done for attributes..
Namespaces are used to avoid name collision, and in Ant to locate the
right implementation class. That's necessary for top-level tasks, and
for nested elements in tasks/types having add(Xyx) methods.
Attributes in Ant OTOH, are always "resolved" relative to their
element. Their can't be any ambiguity ATM for attribute. Ant doesn't
support namespace'd attribute at all, AFAIK.
Also, remember that attributes don't inherit the namespace of their
element, and are always in the "" namespace, unless explicitly
qualified with a prefix. As I write above, Ant doesn't support them
for introspected class.
Using namespace prefixes is dangerous, because they can change from
element to element, depending on while namespaces are in scope, and we
can have different prefixes for the same NS URI, or the same prefix
for different NS URIs depending on the element (although this is evil,
XML supports it).
XmlFragment is already not "exact" XML, as all text nodes, even with
nested element in between them, are merged together. I'm not sure it's
worth it to be exact XML... --DD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: QName in DynamicAttributeNS
Posted by Peter Reilly <pe...@gmail.com>.
The prefix for elements (as against attributes) are retained.
ProjectHelper2 called UE.setQName(qName) with the
name it receives from the sax.
Something needs to be done for attributes..
Peter
On 6/13/06, Steve Loughran <st...@apache.org> wrote:
>
> Peter Reilly wrote:
> > Internally in ant the <uri>:<name> form is used (rather
> > that {uri}name) for a stringized versions of xml namespaced names.
> >
> > In dom it seems that the prefix is used in the qualified name.
> > so e.setAttributeNS(uri, qName, value) should be of
> > the form:
> >
> > e.setAttributeNS("http://example.com", "abc:hello", "hello world")
>
> exactly. Its like xsd:qname and not javax.xml.QName
>
> So XmlFragment is mixing things up.
>
> > (see:
> http://www.oasis-open.org/archives/cgmo-webcgm/200411/msg00004.html)
> >
> > Unfortunally the ant code does not retain the prefix of the attribute
> > (encoded
> > in the qname) see ProjectHelper2:line 1048.
>
> hmm. That is certainly a problem. at the very least, all xmlns
> declarations associated with a node should be retained (in Task?) so
> that you can work out the prefix for yourself, if you know how to
> resolve stuff. (that is actually why I hate xsd:qname, it can only be
> expanded if you know where it should be parsed from, and have the entire
> object graph to hand). Some representation like (uri,localname) makes
> much more sense.
>
> -steve
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
Re: QName in DynamicAttributeNS
Posted by Steve Loughran <st...@apache.org>.
Peter Reilly wrote:
> Internally in ant the <uri>:<name> form is used (rather
> that {uri}name) for a stringized versions of xml namespaced names.
>
> In dom it seems that the prefix is used in the qualified name.
> so e.setAttributeNS(uri, qName, value) should be of
> the form:
>
> e.setAttributeNS("http://example.com", "abc:hello", "hello world")
exactly. Its like xsd:qname and not javax.xml.QName
So XmlFragment is mixing things up.
> (see: http://www.oasis-open.org/archives/cgmo-webcgm/200411/msg00004.html)
>
> Unfortunally the ant code does not retain the prefix of the attribute
> (encoded
> in the qname) see ProjectHelper2:line 1048.
hmm. That is certainly a problem. at the very least, all xmlns
declarations associated with a node should be retained (in Task?) so
that you can work out the prefix for yourself, if you know how to
resolve stuff. (that is actually why I hate xsd:qname, it can only be
expanded if you know where it should be parsed from, and have the entire
object graph to hand). Some representation like (uri,localname) makes
much more sense.
-steve
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: QName in DynamicAttributeNS
Posted by Peter Reilly <pe...@gmail.com>.
Internally in ant the <uri>:<name> form is used (rather
that {uri}name) for a stringized versions of xml namespaced names.
In dom it seems that the prefix is used in the qualified name.
so e.setAttributeNS(uri, qName, value) should be of
the form:
e.setAttributeNS("http://example.com", "abc:hello", "hello world")
(see: http://www.oasis-open.org/archives/cgmo-webcgm/200411/msg00004.html)
Unfortunally the ant code does not retain the prefix of the attribute
(encoded
in the qname) see ProjectHelper2:line 1048.
Peter
On 6/13/06, Stephane bailliez <sb...@apache.org> wrote:
>
>
> I would say DOM is a bit 'flexible' about that as this was not very much
> specified, so implementation more or less allow it and try to do some
> kind of magic later one to try to make sense of it. But my understanding
> is that you are correct.
>
> You have some info about it though:
>
> http://www.w3.org/TR/2003/CR-DOM-Level-3-Core-20031107/namespaces-algorithms.html
>
>
>
> Steve Loughran wrote:
> >
> > I'm now looking at the namespace aware dynamic attribute stuff
> >
> > The qname parameter for this is built up as follows:
> > String qName = ("".equals(uri)
> > ? localName : (uri + ":" + localName));
> >
> >
> > this is not how, say, Qname.toString() presents qnames, which is
> > {http://example.org}tag
> >
> > I'd change it, but then I looked at how XmlFragment handled it, which
> > it does by handing it off to the Dom element
> >
> > e.setAttributeNS(uri, qName, value);
> >
> > I dont use classic DOM. but from what the javadocs imply, this appears
> > wrong. the qname that Element.setAttributeNS() seems to want is a
> > classic prefix:value tuple, like "xmlns:name" or "ant:example".
> >
> > So really we should pass down the prefix and localname, as the uri
> > comes down in the namespace URI param:
> >
> > String qName = ("".equals(uri)
> > ? localName : (prefix + ":" +
> > localName));
> >
> > Am I right here? This is not shipping code so we have time to correct
> > it, but I'd need input from someone who knows Dom intimately enough to
> > get it right. Me, I use Xom :)
> >
> > -steve
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> > For additional commands, e-mail: dev-help@ant.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
Re: QName in DynamicAttributeNS
Posted by Stephane bailliez <sb...@apache.org>.
I would say DOM is a bit 'flexible' about that as this was not very much
specified, so implementation more or less allow it and try to do some
kind of magic later one to try to make sense of it. But my understanding
is that you are correct.
You have some info about it though:
http://www.w3.org/TR/2003/CR-DOM-Level-3-Core-20031107/namespaces-algorithms.html
Steve Loughran wrote:
>
> I'm now looking at the namespace aware dynamic attribute stuff
>
> The qname parameter for this is built up as follows:
> String qName = ("".equals(uri)
> ? localName : (uri + ":" + localName));
>
>
> this is not how, say, Qname.toString() presents qnames, which is
> {http://example.org}tag
>
> I'd change it, but then I looked at how XmlFragment handled it, which
> it does by handing it off to the Dom element
>
> e.setAttributeNS(uri, qName, value);
>
> I dont use classic DOM. but from what the javadocs imply, this appears
> wrong. the qname that Element.setAttributeNS() seems to want is a
> classic prefix:value tuple, like "xmlns:name" or "ant:example".
>
> So really we should pass down the prefix and localname, as the uri
> comes down in the namespace URI param:
>
> String qName = ("".equals(uri)
> ? localName : (prefix + ":" +
> localName));
>
> Am I right here? This is not shipping code so we have time to correct
> it, but I'd need input from someone who knows Dom intimately enough to
> get it right. Me, I use Xom :)
>
> -steve
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: QName in DynamicAttributeNS
Posted by Steve Loughran <st...@apache.org>.
Peter Reilly wrote:
> I guess that it only got exercises with simple examples:
>
> I tried the echoxml:
> <project xmlns:abc="a.b.c" xmlns:def="d.e.f">
> <echoxml>
> <abc:hello abc:a="abc" def:b="def">
> world
> </abc:hello>
> </echoxml>
> </project>
>
> and got:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <abc:hello a="abc" d.e.f:b="def">world</abc:hello>
>
> Which has two problems
> 1 no mapping of prefix to uri
> 2 def:b gets reformed as d.e.f:b
yeah, I knew echoxml didnt handle xmlns properly, I guess now we have
found a cause.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: QName in DynamicAttributeNS
Posted by Steve Loughran <st...@apache.org>.
Igor Peshansky wrote:
> Peter,
>
> You just got lucky because d.e.f is a valid XML name. If you try a full
> URL (e.g., "http://d.e.f"), you'll get a nasty exception.
>
> Technically, DOM keeps the actual namespace URI for all attributes, so
> if ant keeps the prefix for all the elements, you can probably look up
> the appropriate prefix for a given namespace. However, if some esoteric
> namespace is used for all attributes that is different from that of any
> element, you'll need to do more work to keep the attribute prefix
> around.
> Igor
yes, I guess you could walk backwards from the URI to the xmns
declaration, and come up with (some) prefix that matches. alternatively
you could take the (uri,localname) tuple and make up your own prefix to
go with it.
-steve
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: QName in DynamicAttributeNS
Posted by Igor Peshansky <ig...@us.ibm.com>.
Peter,
You just got lucky because d.e.f is a valid XML name. If you try a full
URL (e.g., "http://d.e.f"), you'll get a nasty exception.
Technically, DOM keeps the actual namespace URI for all attributes, so
if ant keeps the prefix for all the elements, you can probably look up
the appropriate prefix for a given namespace. However, if some esoteric
namespace is used for all attributes that is different from that of any
element, you'll need to do more work to keep the attribute prefix
around.
Igor
"Peter Reilly" wrote on 06/13/2006 01:05:46 PM:
> I guess that it only got exercises with simple examples:
>
> I tried the echoxml:
> <project xmlns:abc="a.b.c" xmlns:def="d.e.f">
> <echoxml>
> <abc:hello abc:a="abc" def:b="def">
> world
> </abc:hello>
> </echoxml>
> </project>
>
> and got:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <abc:hello a="abc" d.e.f:b="def">world</abc:hello>
>
> Which has two problems
> 1 no mapping of prefix to uri
> 2 def:b gets reformed as d.e.f:b
>
> Peter
> On 6/13/06, Igor Peshansky <ig...@us.ibm.com> wrote:
> >
> > Steve Loughran wrote on 06/13/2006 06:24:45 AM:
> >
> > > I'm now looking at the namespace aware dynamic attribute stuff
> > >
> > > The qname parameter for this is built up as follows:
> > > String qName = ("".equals(uri)
> > > ? localName : (uri + ":" +
localName));
> > >
> > >
> > > this is not how, say, Qname.toString() presents qnames, which is
> > > {http://example.org}tag
> > >
> > > I'd change it, but then I looked at how XmlFragment handled it,
which it
> >
> > > does by handing it off to the Dom element
> > >
> > > e.setAttributeNS(uri, qName, value);
> > >
> > > I dont use classic DOM. but from what the javadocs imply, this
appears
> > > wrong. the qname that Element.setAttributeNS() seems to want is a
> > > classic prefix:value tuple, like "xmlns:name" or "ant:example".
> > >
> > > So really we should pass down the prefix and localname, as the uri
comes
> >
> > > down in the namespace URI param:
> > >
> > > String qName = ("".equals(uri)
> > > ? localName : (prefix + ":" +
> > localName));
> > >
> > > Am I right here? This is not shipping code so we have time to
correct
> > > it, but I'd need input from someone who knows Dom intimately enough
to
> > > get it right. Me, I use Xom :)
> > >
> > > -steve
> >
> > Steve,
> >
> > Yes, you are correct. The prefix value is not used when serializing
> > and/or
> > comparing QNames. The setAttributeNS method extracts the prefix part
from
> > the qName parameter and sets it on the Attr node (whether new or
> > existing).
> > The prefix is optional -- you should be able to simply pass the
localName
> > in, independent of whether the namespace is present.
> >
> > What I'm surprised at is that not only is this not shipping code, this
> > code
> > is apparently not exercised at all, since the two implementations I
looked
> > at will throw an exception if you try to use the URI as the prefix in
the
> > way that the code you quoted does.
> > Igor
--
Igor Peshansky (note the spelling change!)
IBM T.J. Watson Research Center
XJ: No More Pain for XML's Gain (http://www.research.ibm.com/xj/)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: QName in DynamicAttributeNS
Posted by Peter Reilly <pe...@gmail.com>.
I guess that it only got exercises with simple examples:
I tried the echoxml:
<project xmlns:abc="a.b.c" xmlns:def="d.e.f">
<echoxml>
<abc:hello abc:a="abc" def:b="def">
world
</abc:hello>
</echoxml>
</project>
and got:
<?xml version="1.0" encoding="UTF-8"?>
<abc:hello a="abc" d.e.f:b="def">world</abc:hello>
Which has two problems
1 no mapping of prefix to uri
2 def:b gets reformed as d.e.f:b
Peter
On 6/13/06, Igor Peshansky <ig...@us.ibm.com> wrote:
>
> Steve Loughran wrote on 06/13/2006 06:24:45 AM:
>
> > I'm now looking at the namespace aware dynamic attribute stuff
> >
> > The qname parameter for this is built up as follows:
> > String qName = ("".equals(uri)
> > ? localName : (uri + ":" + localName));
> >
> >
> > this is not how, say, Qname.toString() presents qnames, which is
> > {http://example.org}tag
> >
> > I'd change it, but then I looked at how XmlFragment handled it, which it
>
> > does by handing it off to the Dom element
> >
> > e.setAttributeNS(uri, qName, value);
> >
> > I dont use classic DOM. but from what the javadocs imply, this appears
> > wrong. the qname that Element.setAttributeNS() seems to want is a
> > classic prefix:value tuple, like "xmlns:name" or "ant:example".
> >
> > So really we should pass down the prefix and localname, as the uri comes
>
> > down in the namespace URI param:
> >
> > String qName = ("".equals(uri)
> > ? localName : (prefix + ":" +
> localName));
> >
> > Am I right here? This is not shipping code so we have time to correct
> > it, but I'd need input from someone who knows Dom intimately enough to
> > get it right. Me, I use Xom :)
> >
> > -steve
>
> Steve,
>
> Yes, you are correct. The prefix value is not used when serializing
> and/or
> comparing QNames. The setAttributeNS method extracts the prefix part from
> the qName parameter and sets it on the Attr node (whether new or
> existing).
> The prefix is optional -- you should be able to simply pass the localName
> in, independent of whether the namespace is present.
>
> What I'm surprised at is that not only is this not shipping code, this
> code
> is apparently not exercised at all, since the two implementations I looked
> at will throw an exception if you try to use the URI as the prefix in the
> way that the code you quoted does.
> Igor
> --
> Igor Peshansky (note the spelling change!)
> IBM T.J. Watson Research Center
> XJ: No More Pain for XML's Gain (http://www.research.ibm.com/xj/)
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
Re: QName in DynamicAttributeNS
Posted by Igor Peshansky <ig...@us.ibm.com>.
Steve Loughran wrote on 06/13/2006 06:24:45 AM:
> I'm now looking at the namespace aware dynamic attribute stuff
>
> The qname parameter for this is built up as follows:
> String qName = ("".equals(uri)
> ? localName : (uri + ":" + localName));
>
>
> this is not how, say, Qname.toString() presents qnames, which is
> {http://example.org}tag
>
> I'd change it, but then I looked at how XmlFragment handled it, which it
> does by handing it off to the Dom element
>
> e.setAttributeNS(uri, qName, value);
>
> I dont use classic DOM. but from what the javadocs imply, this appears
> wrong. the qname that Element.setAttributeNS() seems to want is a
> classic prefix:value tuple, like "xmlns:name" or "ant:example".
>
> So really we should pass down the prefix and localname, as the uri comes
> down in the namespace URI param:
>
> String qName = ("".equals(uri)
> ? localName : (prefix + ":" +
localName));
>
> Am I right here? This is not shipping code so we have time to correct
> it, but I'd need input from someone who knows Dom intimately enough to
> get it right. Me, I use Xom :)
>
> -steve
Steve,
Yes, you are correct. The prefix value is not used when serializing
and/or
comparing QNames. The setAttributeNS method extracts the prefix part from
the qName parameter and sets it on the Attr node (whether new or
existing).
The prefix is optional -- you should be able to simply pass the localName
in, independent of whether the namespace is present.
What I'm surprised at is that not only is this not shipping code, this
code
is apparently not exercised at all, since the two implementations I looked
at will throw an exception if you try to use the URI as the prefix in the
way that the code you quoted does.
Igor
--
Igor Peshansky (note the spelling change!)
IBM T.J. Watson Research Center
XJ: No More Pain for XML's Gain (http://www.research.ibm.com/xj/)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org