Re: Name space for XML Invoice Parser
[email protected] (Neil Bowers) Tue, 11 Jun 2024 15:28:58 +0100
| Newsgroups | perl.module-authors |
|---|---|
| Message-ID | <31d53c57-7bee-4f91-be43-a898016ecf33@Spark> |
--66685f2f_3f06ecb2_f1f7 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Johannes, I think the namespace XML::Invoice is fine. I thought it would be helpful= to mention a namespace / permissions constraint you should be aware of, = for CPAN. I'm guessing that your parser produces objects that are instances of XML:= :Invoice=3F I would call the CPAN distribution XML-Invoice, and assume it would conta= in at least two classes: XML::Invoice and XML::Invoice::Parser=3F And a l= ater release might also include XML::Invoice::Generator. When you release something to CPAN (by uploading it to PAUSE), you must h= ave a module with a name that corresponds to the distribution name. So if= you release a distribution XML-Invoice, it has to contain a module XML::= Invoice, and either (a) there are currently no indexing permissions on XM= L:::Invoice (in which case you'll be granted the first-come indexing perm= ission), or (b) you already have an indexing permission (either first-com= e or co-maint) on XML::Invoice. We occasionally see problems where someon= e releases a distribution with a name like Image-=46ormats which contains= Image::=46ormats::PNG, Image::=46ormats::JPEG, etc, but no Image::=46orm= ats module. This constraint was added to PAUSE so that people couldn't ju= mp in and snatch the first-come indexing permission on a module name that= clearly should be associated with some existing module names. The other option is that you could call your parser XML::InvoiceParser, a= nd have XML::InvoiceParser::Invoice for the invoice objects. But I think = that's clunky, and leaves XML::Invoice unclaimed, for someone else to bag= . Neil On Jun 11, 2024 at 2:20=E2=80=AFPM +0100, Johannes Grassler <johannes=40b= tw23.de>, wrote: > Hello, > > I wrote a parser module for various XML based invoice formats, mainly > EN16931=5B0=5D ones, that turns them into Perl objects: > > https://github.com/jgrassler/XML-Invoice-Parser > > I originally contributed this module to the ERP system Kivitendo=5B3=5D= . > Subsequently, I have been getting a bit tired of copying and pasting > the code from that module into various command line tools I've written > for personal use. Since others may also find it similarly useful, I'd > like to release it as a standalone module. > > Now I've been pondering what name space to put it in. I've settled on > XML::Invoice::Parser for now since it's designed to be extensible to > cover other XML based invoice formats=5B2=5D. Also, the XML::Invoice > namespace can at a later stage be used for a generator module I am > toying with the idea of writing. > > Does that sound sensible or does anyone have a better suggestion=3F > > Cheers, > > Johannes > > > =46ootnotes: > > =5B0=5D A EU standard that's either already law or being legislated > as mandatory format for B2B invoices in EU member states. > =5B1=5D https://github.com/kivitendo/kivitendo-erp/tree/master/SL/XMLIn= voice > =5B2=5D I am quite sure there is going to be no shortage of committees > itching to come up with additional formats and new revisions in > the foreseeable future. > > -- > WWW: http://btw23.de/johannes/ > GPG Key fingerprint: 2A3=46 5=46EC D752 944C BD9C B25A 651A B200 1434 C= 358 --66685f2f_3f06ecb2_f1f7 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline <html xmlns=3D=22http://www.w3.org/1999/xhtml=22> <head> <title></title> </head> <body> <div name=3D=22messageBodySection=22> <div dir=3D=22auto=22>Hi Johannes,<br /> <br /> I think the namespace XML::Invoice is fine. I thought it would be helpful= to mention a namespace / permissions constraint you should be aware of, = for CPAN.<br /> <br /> I'm guessing that your parser produces objects that are instances of XML:= :Invoice=3F<br /> <br /> I would call the CPAN distribution XML-Invoice, and assume it would conta= in at least two classes: XML::Invoice and XML::Invoice::Parser=3F And a l= ater release might also include XML::Invoice::Generator.&=23160;<br /> <br /> When you release something to CPAN (by uploading it to PAUSE), you must h= ave a module with a name that corresponds to the distribution name. So if= you release a distribution XML-Invoice, it has to contain a module XML::= Invoice, and either (a) there are currently no indexing permissions on XM= L:::Invoice (in which case you'll be granted the first-come indexing perm= ission), or (b) you already have an indexing permission (either first-com= e or co-maint) on XML::Invoice. We occasionally see problems where someon= e releases a distribution with a name like Image-=46ormats which contains= Image::=46ormats::PNG, Image::=46ormats::JPEG, etc, but no Image::=46orm= ats module. This constraint was added to PAUSE so that people couldn't ju= mp in and snatch the first-come indexing permission on a module name that= clearly should be associated with some existing module names.<br /> <br /> The other option is that you could call your parser XML::InvoiceParser, a= nd have XML::InvoiceParser::Invoice for the invoice objects. But I think = that's clunky, and leaves XML::Invoice unclaimed, for someone else to bag= .<br /> <br /> Neil<br /></div> </div> <div name=3D=22messageReplySection=22>On Jun 11, 2024 at 2:20=E2=80=AFPM = +0100, Johannes Grassler <johannes=40btw23.de>, wrote:<br /> <blockquote type=3D=22cite=22>Hello,<br /> <br /> I wrote a parser module for various XML based invoice formats, mainly<br = /> EN16931=5B0=5D ones, that turns them into Perl objects:<br /> <br /> https://github.com/jgrassler/XML-Invoice-Parser<br /> <br /> I originally contributed this module to the ERP system Kivitendo=5B3=5D.<= br /> Subsequently, I have been getting a bit tired of copying and pasting<br /= > the code from that module into various command line tools I've written<br= /> for personal use. Since others may also find it similarly useful, I'd<br = /> like to release it as a standalone module.<br /> <br /> Now I've been pondering what name space to put it in. I've settled on<br = /> XML::Invoice::Parser for now since it's designed to be extensible to<br /= > cover other XML based invoice formats=5B2=5D. Also, the XML::Invoice<br /= > namespace can at a later stage be used for a generator module I am<br /> toying with the idea of writing.<br /> <br /> Does that sound sensible or does anyone have a better suggestion=3F<br />= <br /> Cheers,<br /> <br /> Johannes<br /> <br /> <br /> =46ootnotes:<br /> <br /> =5B0=5D A EU standard that's either already law or being legislated<br />= as mandatory format for B2B invoices in EU member states.<br /> =5B1=5D https://github.com/kivitendo/kivitendo-erp/tree/master/SL/XMLInvo= ice<br /> =5B2=5D I am quite sure there is going to be no shortage of committees<br= /> itching to come up with additional formats and new revisions in<br /> the foreseeable future.<br /> <br /> --<br /> WWW: http://btw23.de/johannes/<br /> GPG Key fingerprint: 2A3=46 5=46EC D752 944C BD9C B25A 651A B200 1434 C35= 8<br /></blockquote> </div> </body> </html> --66685f2f_3f06ecb2_f1f7--