Using the Frontier XMLRPC system, I encountered a strange inconsisten encoding of the ampersand. In passed scalars all ampersands are always encoded, like the specification sais. Using this function.

sub _scalar {
    my $self = shift; my $value = shift;

    # these are from `perldata(1)'
    if ($value =~ /^[+-]?\d+$/) {
    return ("<value><i4>$value</i4></value>");
    } elsif ($value =~ /^(-?(?:\d+(?:\.\d*)?|\.\d+)|([+-]?)(?=\d|\.\d)
+\d*(\.\d*)?([Ee]([+-]?\d+))?)$/) {
    return ("<value><double>$value</double></value>");
    } else {
    $value =~ s/([&<>\"])/$char_entities{$1}/ge;
    return ("<value><string>$value</string></value>");
    }
}
[download]

Now I changed the data structure in my script and passed all data in a hash, where the hash-keys, again, might contain ampersands. Expecting that Frontier would take over encoding for me I saw no problem, but it ran into an error.

As it turned out hash-keys are not automatically encoded.

sub _hash {
    my $self = shift; my $hash = shift;

    my @text = "<value><struct>\n";

    my ($key, $value);
    while (($key, $value) = each %$hash) {
    push (@text,
          "<member><name>$key</name>",
          $self->_item($value),
          "</member>\n");
    }

    push @text, "</struct></value>\n";

    return @text;
}
[download]

But WHY?? Isn't the Frontier module meant to take over the gory details for me? Can somebody give me a good reason for not writing a fork with this bug(?) fixed?