I ended up using a hash member after all:

sub store_position
 {
 my( $t, $elt)= @_;
 my $line   = $t->{twig_parser}->current_line;    # $t->{twig_parser} 
+is the expat object
 my $column = $t->{twig_parser}->current_column;
 $elt->{custom_atts}{position}= [$line, $column];   # crude but works
 }
[download]

The compelling reason was because I can't assume that the attr mechanism would handle anything other than strings, while a custom-data ability would be defined to handle any Perl object.

I still agree that you should simply document the hash key. But, that also exposes that it =is= a hash, so having get/set custom data members would be better.

I mentioned before that an advantage to using att() is that the normal selection mechanisms work. Here are two more: I can have an explicit line/col in an XML document, much as the #line directive is used in C/C++ -- it can reference the original document's source location. Second, when I add or transform elements (e.g. with split) the new ones don't have this row/col information. An att() could automatically inherit the value from the parent. A documented get_custom_data(KEY) function could also be programmed to inherit.

—John