Re: pageranking perl modules
On Fri, 20 Feb 2004, David Manura wrote: Since there has been some discussion recently on improving search.cpan.org search results, here's an initial attempt to apply the Google-inspired PageRank algorithm on Perl modules when interpreting module dependencies as links: = CPAN top 10 = XML::Parser : 7.68246933302234 First, good job! Then a comment on the area I know best, that shows the limits of the method (which doesn't mean that it is not useful, au contraire, just that the results should come with a warning). I don't know whether it's the same in other cases: lots of modules depend on XML::Parser, but that doesn't make it the right tool to use to parse XML. In fact one of the reason so many other modules were written on top of XML::Parser is that there is quite a bit of a learning curve when you start using it. -- Michel Rodriguez Perl amp; XML http://www.xmltwig.com
Re: Module lists: defining the problem, restating the goals [was Re: OK, so we've decided...]
Hi, I think an interesting angle, first to get an idea of what the problem is, and later (hopefully!) to see if we have improved the situation, is to put ourselves in the position of a Perl programer that doesn't know the community, maybe doesn't even know that CPAN exists. Her first reflex would probably to google for perl + keyword. So let's see what she'd get for some sample keywords: perl xml perl-xml mailing list archive perl-xml FAQ perl date perl-date-time cvs.sourceforge.net/cgi-bin/ viewcvs.cgi/perl-date-time/ perl time nothing really interesting perl database recent useless article dbi.perl.org perl oracle nothing really interesting perl mysql nothing really interesting perl cgi Matt's Script Archive ??? perl mail an old article http://alma.ch/perl/mail.html perl csv 2cd hit: a 2001 page about a non-CPAN CVS module http://rath.ca/Misc/Perl_CSV/index.shtml Not great hey? (At least the Perl-XML folks got it right, props to Grant McLean!). After looking at the results, it seems to me that one of the problems here is that you can't really link to CPAN: there is no single URL for the latest docs of a module, so they are never properly indexed by search engines.A simple step would be to have a single, static, doc page for each module, generated for each new release, but with a stable and easy to remember URL. Then we can start refering and linking to it, and Google can perform its role and we shall be happy for ever after (or at least we can find something else to do with our time ;--). Generating the doc (from the POD) for each module (with a link to the tarfile or to the CPAN search page for the lates release of the module), and putting it on CPAN in something like cpan.org/docs/module name. If size is a problem for mirrors, then a shorter version, with just links to the docs, would work, maybe the search.cpan.org results for example: http://search.cpan.org/~timb/DBI-1.40/ could be statically generated to just http://cpan.org/docs/DBI/index.html Does this make sense? -- Michel Rodriguez Perl amp; XML http://www.xmltwig.com
Re: Module lists: defining the problem, restating the goals [was Re: OK, so we've decided...]
On 16 Feb 2004, Ask Bjoern Hansen wrote: [EMAIL PROTECTED] (Michel Rodriguez) writes: [...] If size is a problem for mirrors, then a shorter version, with just links to the docs, would work, maybe the search.cpan.org results for example: http://search.cpan.org/~timb/DBI-1.40/ could be statically generated to just http://cpan.org/docs/DBI/index.html http://search.cpan.org/dist/DBI/ works. Why should it go on www.cpan.org rather than just be on search.cpan.org? OK, I stand corrected. Then the problem is why don't those pages show up higher when you search on google? They come back fast enough, I suppose they are static, can anyone confirm this? There doesn't seem to be a robots.txt preventing them to be spidered, so they should be indexed. I guess it becomes a social (for lack of a better term) instead of a technical issue: this is what we should link to when we want to reference a module. The fact that I did not know about those shows first that I am quite dumb, but also that even someone who should know about it, well... doesn't. Should we spread the word (through the FAQ? I can post something on PerlMonks) that this should be the proper way to reference modules? -- Michel Rodriguez Perl amp; XML http://www.xmltwig.com
Re: Module lists: defining the problem, restating the goals [was Re: OK, so we've decided...]
On Mon, 16 Feb 2004, A. Pagaltzis wrote: * Michel Rodriguez [EMAIL PROTECTED] [2004-02-16 10:57]: (At least the Perl-XML folks got it right, props to Grant McLean!). You don't put yourself in a particular spot on Google, you just get there by being linked from lots of places. You have zero control over whether and where you appear in the results for a query. there is no single URL for the latest docs of a module, so they are never properly indexed by search engines. Did you try searching for a module name? Go look up, I dunno, Compress::Zlib or something on Google. The 2 things are linked: if people know that there is single, static page to link to when articles, web pages, posts on perlmonks of messages in mewsgroups or in archived mailing lists, then this page will rise through Google rankings and come up when people search for perl and a relevant term. As for finding Compress::Zlib... If you already know what you are looking for, then of course you will find it. In this case a naive user would be lucky though, as 'perl+gzip' returns a link to the doc for Nick Clark's PerlIO-gzip-0.15 (which doesn't have any link to download the module itself, drat!). I think having a convention to link to http://search.cpan.org/dist/* would give these pages a chance to be more visible for programers who don't know about CPAN, or who are overwhelmed by it. The remaining problem I see is that the dist/ pages contain only the one-line description for the module, so there is a risk there that some useful keywords might be missing (Compress::Zlib mentions the zlib library but not gzip for example). Improvement ideas welcome... -- Michel Rodriguez Perl amp; XML http://www.xmltwig.com
Re: OK, so we've decided that the right modules are too hard to find.
On Mon, 16 Feb 2004, khemir nadim wrote: Please don't shout if it's note to show you're happy. Check the discussion we had about Roman.pm a few weeks ago. My point is not to force anyone to develop anything but that when a module is released and the author can't maintain it, the curators job would be to design a new maintainer. Period. Going back to Roman.pm (I was on vacation when you first posted, hence no answer at the time), if a PAUSE admin wants the email of the original creator, (he seems a bit paranoiac about letting it displayed in the wwwild), I have it, so he can gain the rights to maintain his own module ;--) -- Michel Rodriguez Perl amp; XML http://www.xmltwig.com
Re: Finding the module you want (was: New module Mail::SendEasy)
On Tue, 10 Feb 2004, Dave Rolsky wrote: On Tue, 10 Feb 2004, A. Pagaltzis wrote: * It's better to have comparative articles than module centric reviews; they're also less susceptible to manipulation. I think these are great. The problem is they're a lot of work. I've written two (POOP and date/time) and I know Perrin wrote one for templating systems. They require you to look at _lots_ of modules and also to have a good understanding of all the problems that need to be solved in the area. Not that I'm trying to discourage anyone, just pointing out that it's a non-trivial task. I can concurr. I have written a bunch about XML modules (http://xmltwig.com/article/) and even the simplest ones, like the Ways to Rome series, take quite a long time to write. -- Michel Rodriguez Perl amp; XML http://www.xmltwig.com
Re: New version of Roman available
On Wed, 7 Jan 2004, Andy Lester wrote: A while back I asked if it was possible for me to take over the maintenance of Roman.pm. I got no answer... Did you contact the original author? Any response? As it turns out I found the author... but as Roman predates PAUSE et he has been away for a while, it looks like he can't update the module either! -- Michel Rodriguez Perl amp; XML http://www.xmltwig.com
New version of Roman available
Hi, A while back I asked if it was possible for me to take over the maintenance of Roman.pm. I got no answer... So anyway, a version with a Makefile.PL, tests and support for numbers above 4000 is available at http://xmltwig.com/module/roman/ Is there anyway this version could end up on CPAn as the official Roman.pm? At least it can be installed using the traditional 'perlMakefile.PL; make;make test; sudo make install;' incantation (note that CPANPLUS install the current version properly). -- Michel Rodriguez Perl amp; XML http://www.xmltwig.com
RFC: Data::Traverse
but reads better). prune if the handler returns prune then the children of the current item are not traversed finish ends the traversal and returns BUGS/TODO At this point cycles in the data structure are not properly processed: - the procedural interface will most likely enter deep recursion, - the OO interface will only get once to each item, but then testing the context will only occur once The procedural interface does a breadth-first traversal of the data, the OO interface does a depth-first traversal, it would be nice to be able to choose the algorithm. More tests need to be written (isn't this always the case? ;--) It would be nice to have more generic methods to query the context (XPath-based?) -- Michel Rodriguez Perl amp; XML http://www.xmltwig.com
Re: New version of Roman available
On Wed, 7 Jan 2004, Andy Lester wrote: A while back I asked if it was possible for me to take over the maintenance of Roman.pm. I got no answer... Did you contact the original author? Any response? Yes, I have tried several times in the last 3 years, with no result. I might have found a more recent email address though, so I tried again today. -- Michel Rodriguez Perl amp; XML http://www.xmltwig.com
Re: RFC: Date::Iterator
On Fri, 19 Dec 2003, Marco Marongiu wrote:
Dave Rolsky wrote:
[...]
How hard is that?
my $i = Date::Iterator-new( from = [2003,10,3], to = [2003,11,10] ) ;
while (my $day = $i-next) { ... }
Is this harder?
What does your module offer that makes it worth _not_ getting all the
other features DateTime.pm offers [...]
Maybe the fact that I don't need all the other features?
I believe this kind of attitude leads to dilution of efforts and lowers
the usefulness of CPAN. I know it is hard to decide to abandon a module
that you spent some time writing and whose interface you are (obviously)
quite happy with. But if you really want to do something useful for the
community, it is nevertheless The Right Thing To Do (tm).
I have more than once started writing code, only to discover, after
discussing it here, that I had overlooked an existing module that did
nearly the same thing. In this case I either just abandon the module, or
put it up on my website but not on CPAN. If I think I came up with an
interesting interface that could improve the existing module, then contact
the author to see if they would be willing to accept a patch.
Polluting CPAN with modules that duplicate existing functionalities is
definitely NOT responsible behaviour, especially in areas like Date:: and
Time:: where there is already much confusion, and an coordinated effort
to fix that confusion through DateTime::
In your case why not see if you can write a patch to one of the DateTime
modules that would give you an interface similar to what you wrote?
--
Michel Rodriguez
Perl amp; XML
http://www.xmltwig.com
Re: RFC: Date::Iterator
On Fri, 19 Dec 2003, Marco Marongiu wrote:
As I said in my first mail, Date::Iterator came out to solve a problem I
had at work. And as it happened to you, I decide to write a new module
after a lot of searching into cpan. DateTime modules didn't come out
from those searches, unfortunately. But, as Dave Rolsky recognized, even
if I found them the documentation itself doesn't encourage people to use
it for simple tasks...
Could I contribute to the DateTime project? I think I can't. Working
with calendars and times would require me an effort bigger than I can
take. If you look at the module code, it am just plain using a single
function from a single module (Date::Calc): I have no experience on
doing things like that myself.
Proliferation of modules on CPAN is evil? Maybe. Maybe not. It could
create confusion, you are right. But... well, I'll say in italian: Cio`
che hai in piu` non ti impoverisce; I don't have a good translation in
english, but it could sound like things you got and don't need don't
make you poor. It's a natural selection process: people search for
modules that do the job, read the docs and make a choice. If my module
is bad, they simply won't use it.
Instead of hiding my module in my insignificant website, wouldn't it be
better to write on top and bottom of the docs an advice like this is a
small module and does a few things; you probabily want to take a look at
DateTime and DateTime::Event::Recurrence http://datetime.perl.org?
OK, that will teach me not to get suckered ino this kind of discussion
;--(
I think your module could be rewritten as syntaxic sugar over the existing
DateTime::* ones (or merged as a patch into an existing one).
It brings 2 things: a compact way to create a date for a day, and a
compact syntax to create an ierator over days. What integrating it into
the DateTime hierarchy would do is to allow it to play nice with the other
modules.
I haven't kept all the mails in the thread so I can't look at your
original code, but I believe the following would work in a similar way. I
would move the simpledate2datetime method somewhere else though, as it is
somewhat orthogonal (do I get points for using this first in this thread?)
to the iteration feature.
Does this make sense?
#!/usr/bin/perl -w
use strict;
# use as a list
my @days = DateTime::Iterator-new( from = 2001-11-03, to = 2001-11-10);
foreach my $day (@days ) { print $day-ymd . \n; }
# use as an iterator
my $days= DateTime::Iterator-new( from = [ 2001, 11, 03], to = [ 2001, 11, 10]);
while( my $day= $days-next) { print $day-ymd . \n; }
package DateTime::Iterator;
use Carp;
use DateTime;
use DateTime::Event::Recurrence;
sub new
{ my( $class, %options)= @_;
carp need a to and from option to daily_sequence
unless( defined( $options{from}) defined( $options{to}));
my $from = simpledate2datetime( $options{from});
my $to = simpledate2datetime( $options{to});
my $daily_set = DateTime::Event::Recurrence-daily;
return wantarray ? $daily_set-as_list( start = $from, end = $to )
: $daily_set-iterator( start = $from, end = $to )
;
}
sub simpledate2datetime
{ my $simpledate= shift;
unless( UNIVERSAL::isa( $simpledate, 'ARRAY'))
{ $simpledate= [split /-/, $simpledate ] }
my %date_args;
@date_args{qw( year month day)}= @$simpledate;
return DateTime-new( %date_args);
}
--
Michel Rodriguez
Perl amp; XML
http://www.xmltwig.com
module discussion: Class::SubclassDeep
Hi, This has happened to me enough tme that I think a module might be in order: I want to subclass an existing class,but I can't: the objects in this class are created by an other existing class. I don't control the way that class creates these objects. Typically, when using an XML parser that creates a tree, I use a module. I create an object ( parser) in that module, which I can sub-class. But then, during the parsing, the parser in turn creates the nodes in the tree. I want to subclass those nodes, typically to add methods, and sometimes data, to them. I see 3 ways to do this: - have the parser provide hooks to subclass the various types of nodes that it creates which is not usually the case... - take a good look at the parser, subclass it, and re-write ALL the methods that create nodes, which seems like a lot of work for what I want to do, - mess with namespaces and add my own new methods to the original node package(s), which I often do, but strikes me as not totally kosher (and in any case it makes changing the constructor of the nodes a bit awkward) So I thought about it, looked around CPAN to figure out if I could find something that would do this, did not find it, and set out to write it myself. I have a first, simple and quite clumsy version. I am looking for a good module name, interface suggestion, and even implementation hints. The first version is called Class::SubclassDeep, it offers a single function (niark, niark! a procedural module to help those poor OO folks lost in their class structure ;--): subclass( class1 = subclass1, class2 = subclass2 (constructor)); This replaces class1::new by a new method, that calls the original method, but blesses the object as subclass1 before returning it. In the class2 case the difference is that the constructor is not called 'new' but 'constructor'. Note that in this version the subclass is not allowed to have its own constructor. I plan to change this by allowing a constructor, that will be able to call the original constructor through a mean to be determined... The original new (or constructor) method is saved in the symbol table as 'new_saved_by_subclassdeep', which is clumsy at best. At the moment it is really a hack, but at least a hack hidden behind a clean interface. Does this makes sense? Did I miss anything? The early version of the module is at http://www.xmltwig/module/class-subclassdeep/ -- Michel Rodriguez Perl amp; XML http://www.xmltwig.com
Ownership of Roman.pm
Hi, I have never figured out how module ownership transfer worked, so I am posting my plea here ;--) The module Roman.pm is quite useful for working with Roman numerals (it is even mentioned in the Cookbook). Saddly it consists only in one file, Roman.pm, with no Makefile.PL nor tests. I have written those and tried to contact the author of the module, the first time 2 years ago, then again this year (see attached message, dated August 14th). Both times I got no answer. The module itself has not been updated since 1997. Would it be possible either for me to get ownership of the module, or just to upload http://www.xmltwig.com/module/roman/Roman-1.2.tar.gz to PAUSE? I also have a proto that supports numbers above 4000 by using the appropriate unicode characters. It works fine but if someone running a Perl pre-5.6.0 could use it, I would like to know how badly it blows without unicode support. This version is at http://www.xmltwig.com/module/roman/Roman-1.3.tar.gz Thanks -- Michel Rodriguez Perl amp; XML http://www.xmltwig.com From [EMAIL PROTECTED] Fri Nov 21 13:28:55 2003 Date: Thu, 14 Aug 2003 13:39:55 +0200 (CEST) From: Michel Rodriguez [EMAIL PROTECTED] To: OZAWA Sakuro [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Roman.pm Hi Sakuro, I have used Roman.pm for a long time and I like it, good job. I have packaged it with a Makefile.PL and tests, it is available at http://xmltwig.com/module/roman/Roman-1.2.tar.gz If you are still maintaining the module you could upload this version to CPAN. Also note that with the addition of unicode to Perl it might be possible to support numbers greater than 4000 now. If you want I can try writing a patch. Thank you Michel Rodriguez Perl amp; XML http://www.xmltwig.com
Re: RFC Format::FileSize
On Wed, 27 Aug 2003, Lars Thegler wrote: I just emailed the author A worthy effort, indeed :) At least I will have gained a better knowledge of CPAN ;--) While you are at it, you might want to support the whole range of SI prefixes (note that these are *not* units, but unit *prefixes*), check out http://physics.nist.gov/cuu/Units/prefixes.html to get them all. And be very careful; not everybody will agree with you that 'M' should mean 1024*1024 - communications people will insist that 64kbps is infact 64*10^3 bps, and not 64*2^10 bps. IEC tried to define new names (kibi instead of kilo for 2^10), but I seriously doubt that these will ever get wider accceptance. The primary use of this module is to display file sizes. It can certainly also display memory sizes, but anything else, while possible (you can configure the units, their relation and so on...) would probably be a stretch. I like the Gibi (the Gibis were a race in a French cartoon that I loved as a kid: http://perso.club-internet.fr/wabnitz/Shadok/Shadok.htm (French)) Also, if you look at harddisk capacity figures, some (most) manufacturers will say '80Gb' meaning 80*10^9 bytes, rather than 80*2^30. Makes the disks appear bigger than they are - standard salesman trick :) You can configure the factor used, not to that level though, I would have either to include this as a special case or to allow complete customization of the unit table. Maybe adding styles for other units would be a good option, if indeed I release the module, which seems doubtfull at this point. Michel Rodriguez Perl amp; XML http://www.xmltwig.com
RFC Format::FileSize
Hi,
I was processing a bunch of files the other day, and I wanted to get a
rough idea of their size.
Oddly enough I could not find anything that seemed to be doing this.
So I wrote Format::FileSize, which exports 1 function, named
formatted_size,
perl -MFormat::FileSize -le'foreach (@ARGV)
{ printf %-12d = %s\n, $_, formatted_size( $_) }' \
0 1 500 1023 1024 1025 2500 25000 \
25 100 2500 25000 \
25
0= 0
1= 1
500 = 500
1023 = 1023
1024 = 1 K
1025 = 1 K
2500 = 2.44 K
25000= 24.4 K
25 = 244 K
100 = 976 K
2500 = 23.8 M
25000= 238 M
-1794967296 = 2.32 G
Does this make sense or does this already exist and I have missed it?
Is Format::FileSize a proper name?
A first version is available at
http://www.xmltwig.com/module/format-filesize/
Thanks
Michel Rodriguez
Perl amp; XML
http://www.xmltwig.com
RE: RFC Format::FileSize
On Wed, 27 Aug 2003, Orton, Yves wrote:
Does this make sense or does this already exist and I have missed it?
Is Format::FileSize a proper name?
Do a search for units on search.cpan.org and i think youll find this
somewhere. And no I dont think the name is that great.
I just did that, but to no avail. This function does not seem to be
available in an existing module.
As far as the name goes, I agree that it is not limited to file size, it
can also be memory, but that's pretty much it, as least out-of-the-box.
You can the configure it to display pretty much anything (not times
though, that's something I won't get involved in ;--). But it does not do
conversion, it just generates a short string that's meaningful enough for
human usage. Quite a few tools use similar algorithms, df, du, and such.
It's really just a way to format a number.
I actually found that Number::Format has a quite similar function, albeit
slightly less configurable.
compare:
perl -MFormat::FileSize -le'foreach (@ARGV)
{ printf %-12d = %s\n, $_, formatted_size( $_) }' 0 1 500 1023 \
1024 1025 2500 25000 25 100 2500 25000 25
0= 0
1= 1
500 = 500
1023 = 1023
1024 = 1 K
1025 = 1 K
2500 = 2.44 K
25000= 24.4 K
25 = 244 K
100 = 976 K
2500 = 23.8 M
25000= 238 M
-1794967296 = 2.32 G
perl -MNumber::Format -le'foreach (@ARGV)
{ printf %-12d = %s\n, $_, Number::Format::format_bytes( $_) }' 0
1 500 1023 1024 1025 2500 25000 25 100 2500 25000 \
25
0= 0
1= 1
500 = 500
1023 = 1,023
1024 = 1,024
1025 = 1K
2500 = 2.44K
25000= 24.41K
25 = 244.14K
100 = 976.56K
2500 = 23.84M
25000= 238.42M
-1794967296 = 2.33G
So maybe Number::Format::FileSize ?
Michel Rodriguez
Perl amp; XML
http://www.xmltwig.com
Re: RFC Params::Normalize
On 24 Jun 2003, William R Ward wrote: [EMAIL PROTECTED] (Michel Rodriguez) writes: Variable/Parameter conventions can start religious wars, so I would like to offer module authors a way to be a little oecumenical, so they can easily offer named parameters that follow the one_true_perl_convention or even the baddlyNamedCamelCaseConvention. Very cool idea. Have you considered using a tied hash interface for this? I think that would be very slick... Excellent idea, I'm on it. Michel Rodriguez Perl amp; XML http://www.xmltwig.com
RFC Params::Normalize
Hi,
Variable/Parameter conventions can start religious wars, so I would like
to offer module authors a way to be a little oecumenical, so they can
easily offer named parameters that follow the one_true_perl_convention or
even the baddlyNamedCamelCaseConvention.
I have looked for a module that would do this, but could not find anything
on CPAN.
So I wrote it.
Does it make sense? Did I miss a module that would do it? Does the name
make sense (other possibilities I can think of would be Params::ChangeName
Params::ConvertName)? Any other comment?
SYNOPSIS
use Params::Normalize qw( perl_style_params);
...
my_sub( $arg, camelCasedOption = 'fooBar',
hideousIMHO = 1,
badBADBad = 'foo'
);
...
sub my_sub
{ my( $arg, @opts)= @_;
my %opts= perl_style_params( @opts);
# %opts is now:
# camel_case_option = 'fooBar',
# hideous_IMHO = 1,
# bad_BAD_bad = 'foo'
...
ABSTRACT
Params::Normalize offers functions to convert named parameters from
perl_style to javaStyle and vice-versa
DESCRIPTION
perl_style_params %opts (or @opts)
Converts the keys of %opts into perl_style keys
javaStyleParams %opts (or @opts)
Converts the keys of %opts into javaStyle keys
JavaStyleParams %opts (or @opts)
Converts the keys of %opts into JavaStyle keys
EXPORT
None by default.
SEE ALSO
perl
AUTHOR
Michel Rodriguez, [EMAIL PROTECTED]
COPYRIGHT AND LICENSE
Copyright 2003 by Michel Rodriguez
This library is free software; you can redistribute it and/or
modify it under the same terms as Perl itself.
Michel Rodriguez
Perl amp; XML
http://www.xmltwig.com
Re: RFC Params::Normalize
On Tue, 24 Jun 2003, Flavio S. Glock wrote: Michel Rodriguez wrote: Variable/Parameter conventions can start religious wars, so I would like to offer module authors a way to be a little oecumenical, so they can easily offer named parameters that follow the one_true_perl_convention or even the baddlyNamedCamelCaseConvention. Param::Validate has some related functionality: my %p = validate_with ( params = [EMAIL PROTECTED], ignore_case = 1, strip_leading = '-', ); Maybe adding a ignore_underline option to Param::Validate would be enough (used with ignore_case) ? I looked at Params::Validate, but it seems to me that the goal of the 2 modules is quite different: Params::Validate does not update the original hash, which is Params::Normalize primary goal. I like the fact that no matter what convention the user code uses I can get the options as perl style in my code, and if needed pass them to a lower-level module that uses the java style (XML modules seem to like it). Params::Check is the closest I have found, as it lets you validate params but also converts all the keys in the hash to lower case (it might be worth adding such an option to Params::Validate). Michel Rodriguez Perl amp; XML http://www.xmltwig.com
RE: RFC Params::Normalize
On Tue, 24 Jun 2003, Hugh S. Myers wrote: How about Params::Styler since it addresses a programming style issue? Params::Style sounds OK to me, version 0.01 is available here: http://xmltwig.com/params_style/ Unless there is a general outcry I will upload it to CPAN tomorrow -- Michel Rodriguez Perl amp; XML http://www.xmltwig.com
Re: New module: XML::Stag - Structured Tag datastructures
On Tue, 2002-11-26 at 06:04, Chris Mungall wrote: I have written a module for manipulating data using Simple Tree AGgregate datastructures (recursive Structured TAGs), currently called XML::Stag This module is primarily a data manipulation tool. The data structure happens to map well to a simplified subset of the XML spec, which means that XML is a useful import/export format (as are lisp-style S-expressions). This module can do a lot of the same things that current XML modules can do (but with important differences, see below), so I think it naturally falls into the XML:: namespace. Logically speaking, an SExpression:: namespace makes as much sense, but XML:: seems a more practical choice. Hi Chris, There are already a whole lot (read, Way Too Many (tm)) modules in the XML namespace (see http://cpan.org/modules/by-category/11_String_Lang_Text_Proc/XML/). So your module might not really stand-out there. It does not seem to be based on an existing parsing library and from what I understand it parses only a subset of XML. This is dangerous too, and I think should be a sign that it does not belong in the XML namespace (and yes, I know there are already modules with those characteristics there, but lets not add to the confusion, we already suffer from the plethora of quasi-XML modules). So I would recommend you put it either in the SExpression namespace (that would be a new namespace right?) or maybe in the Tree namespace where it seems to fit nicely: http://search.cpan.org/modlist/Data_and_Data_Types/Tree Does this make sense? -- Michel Rodriguez [EMAIL PROTECTED]
