I have to think about it. The problem I see is that, although this is a usefull and clever trick, it would probably be used quite infrequently, while slowing down every print or sprint... Though as I would limit it to attributes starting with #, it would only cost one substr() per attribute. I think silently removing all illegal attributes is too dangerous for the user, and checking them might get me into Unicode trouble. Now what about elements names starting with #

BTW if I go this route I might as well add an option to generate the line/column attributes ;--)

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