Skip Menu |
 

This queue is for tickets about the XML-Twig CPAN distribution.

Report information
The Basics
Id: 38384
Status: rejected
Priority: 0/
Queue: XML-Twig

People
Owner: Nobody in particular
Requestors: cpan [...] chmrr.net
Cc:
AdminCc:

Bug Information
Severity: Normal
Broken in: 3.32
Fixed in: (no value)



Subject: Inconsistent prefixing of namespaces on attributes when using map_xmlns
Download (untitled) / with headers
text/plain 550b
When using the map_xmlns parameter, attributes are _sometimes_ prefixed with the tag's namespace, depending on if the namespace in question is the default namespace or not. Attached is simple test demonstrating two semantically equal XML fragments which XML::Twig parses differently, because of this. From the comments around line 2005 of Twig.pm, this is known to be a somewhat weird edge case. I would think that taking the namespace from the tag's namespace, and falling back to '#default' after that, would be a more correct ordering. - Alex
Subject: test-xmlns-attr.t
Download test-xmlns-attr.t
text/x-perl 1.1k
#!/usr/bin/perl -w use Carp; use File::Spec; use lib File::Spec->catdir(File::Spec->curdir,"t"); use tools; use strict; use warnings; $| = 1; use XML::Twig; my $TMAX = 4; print "1..$TMAX\n"; my $default = <<EOT; <?xml version="1.0" encoding="UTF-8"?> <calendar-query xmlns:D="DAV:" xmlns="urn:ietf:params:xml:ns:caldav"> <D:prop> <D:getetag/> </D:prop> <filter> <comp-filter name="VCALENDAR"/> </filter> </calendar-query> EOT my $explicit = <<EOF; <?xml version="1.0" encoding="UTF-8"?> <C:calendar-query xmlns:D="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav" > <D:prop> <D:getetag/> </D:prop> <C:filter> <C:comp-filter name="VCALENDAR"/> </C:filter> </C:calendar-query> EOF for my $text ($default, $explicit) { my $t = XML::Twig->new( map_xmlns => { 'urn:ietf:params:xml:ns:caldav' => 'C', 'DAV:' => 'D', }, ); $t->parse($text); my @nodes = $t->find_nodes("/C:calendar-query/C:filter/C:comp-filter" ); is(@nodes+0, 1, "Right number of nodes"); my %atts = %{ $nodes[0]->atts }; is( join("",keys %atts), "C:name", "Has the 'C:name' property'"); } exit; 1;
Download (untitled) / with headers
text/plain 1.1k
On Sun Aug 10 23:34:56 2008, ALEXMV wrote: Show quoted text
> When using the map_xmlns parameter, attributes are _sometimes_ prefixed > with the tag's namespace, depending on if the namespace in question is > the default namespace or not. Attached is simple test demonstrating two > semantically equal XML fragments which XML::Twig parses differently, > because of this. > From the comments around line 2005 of Twig.pm, this is known to be a > somewhat weird edge case. I would think that taking the namespace from > the tag's namespace, and falling back to '#default' after that, would be > a more correct ordering. > - Alex
Hi, Sorry for the late response. It seems to me that actually XML::Twig behaves properly in this case: the name attribute in you second document does not have a namespace: "The namespace name for an unprefixed attribute name always has no value" (Namespaces in XML 1.0, W3C recommendation: http://www.w3.org/TR/xml-names/#defaulting). Hence the attribute is not prefixed. I have always found it weird that the default namespace does not apply to attributes, but that seems to be what the W3C wants. Does this make sense? __ mirod
Subject: Re: [rt.cpan.org #38384] Inconsistent prefixing of namespaces on attributes when using map_xmlns
Date: Thu, 04 Sep 2008 23:50:18 -0400
To: bug-XML-Twig [...] rt.cpan.org
From: Alex Vandiver <alexmv [...] MIT.EDU>
Download (untitled) / with headers
text/plain 659b
On Mon, 2008-08-25 at 10:57 -0400, MIROD via RT wrote: Show quoted text
> I have always found it weird that the default namespace does not apply > to attributes, but that seems to be what the W3C wants. > > Does this make sense?
Yes; a more careful reading of the XML spec, and of various internet resources discussing this oddity, confirms that you (and XML::Twig) are absolutely correct on this. *sigh* Unfortunately, the various generators of the XML that I'm parsing didn't pick up on this subtlety, so I'll have to hack around it. Thanks for the useful module, and the nudge in the right direction, - Alex -- Networking -- only one letter away from not working


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.