RFC on ISBN sanitisations, was: [Koha-patches] [PATCH] Bugfix ShelfBrowser using unsanitized ISBNs. Owen reported the
Woops, forgot to CC the list. Yes, I think this should be moved to C4. I've been noodling around
with the notion of creating a C4::Normalize or the like to centralize these kinds of normalizations (as ISSNs, LC card numbers, OCLC numbers, etc. could benefit from this as well), but haven't done anything yet.
Regards,
Galen
Do you think we could also put standard formatting of these types of numbers in there, and make a naming scheme? Example: ISBNInternalForm('0-7434-3602-4') eq '0743436024' ISBNDisplayForm('0743436024') eq '0-7434-3602-4' Also LCCNInternalForm and LCCNDisplayForm, etc. The naming scheme is a slightly awkward one, so feel free to modify. It would be nice to have this functionality for other things too, such as C4::Amazon.
Hi, On Wed, May 14, 2008 at 1:59 PM, Jesse <pianohacker@gmail.com> wrote:
Do you think we could also put standard formatting of these types of numbers in there, and make a naming scheme?
Example:
ISBNInternalForm('0-7434-3602-4') eq '0743436024' ISBNDisplayForm('0743436024') eq '0-7434-3602-4'
I agree that some sort of naming convention is in order. In addition to internal (i.e., for search and API use) and display forms, an additional type of normalization would be equivalent forms - I'm thinking specifically of ISBN-10s and ISBN-13s. Checkdigit and form validation may also belong in such a model. One possibility for naming: use C4::Normalize qw/:ISBN/; # or use C4::Normalize::ISBN? my $normed = display_isbn('0743436024'); # 0-7434-3602-4 $normed = display_isbn('0-7434-3602-4'); # 0-7434-3602-4, should be idempotent $normed = search_isbn('0-7434-3602-4'); # 0743436024 $normed = search_isbn('0-7434-3602-4 (pbk.)'); # 0743436024; remove cruft that we can use in search my $ok = valid_isbn('foobar'); # false my $isbn13 = isbn10_to_isbn13('0-7434-3602-4'); Alternatively, does an OO interface get us anything additional that is useful? my $isbn = C4::Normalize::ISBN->new('0-7434-3602-4'); print $isbn->search(); print $isbn->display(); Regards, Galen -- Galen Charlton Koha Application Developer LibLime galen.charlton@liblime.com p: 1-888-564-2457 x709
Galen Charlton a écrit :
Hi,
Hi, I also think this could be a good thing to have a C4::Normalize. (Maybe not for 3.0) Maybe we could broaden the scope. UTF8 Normalize, Normalizing publication dates and acquisition dates, and prices, and maybe even itemcallnumber could also enter this module.
On Wed, May 14, 2008 at 1:59 PM, Jesse <pianohacker@gmail.com> wrote:
Do you think we could also put standard formatting of these types of numbers in there, and make a naming scheme?
Example:
ISBNInternalForm('0-7434-3602-4') eq '0743436024' ISBNDisplayForm('0743436024') eq '0-7434-3602-4'
I agree that some sort of naming convention is in order. In addition to internal (i.e., for search and API use) and display forms, an additional type of normalization would be equivalent forms - I'm thinking specifically of ISBN-10s and ISBN-13s. Checkdigit and form validation may also belong in such a model.
One possibility for naming:
use C4::Normalize qw/:ISBN/; # or use C4::Normalize::ISBN?
my $normed = display_isbn('0743436024'); # 0-7434-3602-4 $normed = display_isbn('0-7434-3602-4'); # 0-7434-3602-4, should be idempotent $normed = search_isbn('0-7434-3602-4'); # 0743436024 $normed = search_isbn('0-7434-3602-4 (pbk.)'); # 0743436024; remove cruft that we can use in search my $ok = valid_isbn('foobar'); # false my $isbn13 = isbn10_to_isbn13('0-7434-3602-4');
Alternatively, does an OO interface get us anything additional that is useful?
my $isbn = C4::Normalize::ISBN->new('0-7434-3602-4'); print $isbn->search(); print $isbn->display() I am not really going in for that. Having pieces written in OO and others in procedural mode is not really good for me. Unless we get into a work of rewriting the code into OO Programming, which would be a HUGE work, maybe highly valuable but I think that having too many objects without good documentation and entry points would really be a waste of time and strength. Let's have this release out and document features and functions. Then time for OO Programming will come at his own pace. -- Henri-Damien LAURENT
On Wed, May 14, 2008 at 2:41 PM, Henri-Damien LAURENT <laurenthdl@alinto.com> wrote:
I am not really going in for that. Having pieces written in OO and others in procedural mode is not really good for me. Unless we get into a work of rewriting the code into OO Programming, which would be a HUGE work, maybe highly valuable but I think that having too many objects without good documentation and entry points would really be a waste of time and strength. Let's have this release out and document features and functions. Then time for OO Programming will come at his own pace.
I recognize your desire for consistency throughout the code. It is a desirable quality. But, I actually believe that new parts that are pretty independent the rest of the code should use an object oriented design when possible. This looks like a good candidate to me. Since moving to OO is a lot of work, I'd rather not add more procedural pieces, and each step towards more OO is less work to be done later. This is not a strong opinion of mine, so I could be convinced otherwise, such as if I'm in a small minority or there are other compelling reasons. I certainly am not the deciding factor here. I took a look at Chapter 15 of Perl Best Practices to see what Conway had to say about when to use OO. I'm not sure which side of the dilemma it comes down on, but it might be helpful to check out if we do actually seem to be somewhat divided on the issue. By the way, I'll never argue against increased documentation, so I think we're together on that one. -Andy _______________________________________________ Koha-devel mailing list Koha-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/koha-devel
OOP versus non-OOP? Should we put this to a list-wide vote, or is there some sort of policy encouraging one way or the other? I know that Koha as it stands is not generally object-oriented, but established conventions don't always reflect policy. In any case, here's my vote: +1 No OOP -1 OOP _______________________________________________ Koha-devel mailing list Koha-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/koha-devel
Jesse <pianohacker@gmail.com> wrote: [ Galen wrote (I think):]
Yes, I think this should be moved to C4. I've been noodling around with the notion of creating a C4::Normalize or the like to centralize these kinds of normalizations (as ISSNs, LC card numbers, OCLC numbers, etc. could benefit from this as well), but haven't done anything yet. [...]
Do you think we could also put standard formatting of these types of numbers in there, and make a naming scheme?
For some reason, emails from liblime.com aren't reaching me promptly today, so I'll reply to both of the above at once:- I suspect C4::Normalize would have poor cohesion (probably logical cohesion) so would prefer creating C4::ISBN and similar, with methods like new($), raw(), normal(), display() and so on. Would the display() methods be best if they use a syspref? Anyway, if this isn't already in there, maybe we should hesitate on adding this new feature. Seems pretty damn compelling to me, though. Hope that helps, -- MJ Ray (slef) Webmaster for hire, statistician and online shop builder for a small worker cooperative http://www.ttllp.co.uk/ http://mjr.towers.org.uk/ (Notice http://mjr.towers.org.uk/email.html) tel:+44-844-4437-237
On Wed, May 14, 2008 at 2:15 PM, MJ Ray <mjr@phonecoop.coop> wrote:
I suspect C4::Normalize would have poor cohesion (probably logical cohesion) so would prefer creating C4::ISBN and similar, with methods like new($), raw(), normal(), display() and so on.
If we're voting, I'm voting for an approach like this. -Andy
For some reason, emails from liblime.com aren't reaching me promptly today, so I'll reply to both of the above at once:-
I suspect C4::Normalize would have poor cohesion (probably logical cohesion) so would prefer creating C4::ISBN and similar, with methods like new($), raw(), normal(), display() and so on.
Eek. There's already a... plethora of modules in C4::. At the very least, we would be adding C4::ISBN, C4::OCLC and C4::LCCN. If we really need an OOP interface (seems like overkill for the simple reformatting this would be doing), we could have C4/Normalize.pm with subpackages in the file like C4::Normalize::ISBN, C4::Normalize::LCCN, etc. Supposing that we used a functional layout, we should probably go with a VerbNoun CamelCase function layout, with very similar names for the ISBN, LCCN, etc. reformatting functions. As long as we stuck to it, this would give us some logical cohesion: "I need to format an LCCN for display, and I know that I used isbn_display_form(); I'll just use lccn_display_form()." ISBNSearchForm or even isbn_search_form get my vote; search_isbn is a tad confusing to me at least, since it evokes C4::Search. Also, as much as I loathe CamelCase, it is the semiofficial koha standard ( http://wiki.koha.org/doku.php?id=en:development:codingguidelines).
Would the display() methods be best if they use a syspref?
Most likely. Different people might like ISBNs chunked in different ways, or even not at all. Anyway, if this isn't already in there, maybe we should hesitate on
adding this new feature. Seems pretty damn compelling to me, though.
I agree; there's a lot of places that need to reformat ISBNs throughout the intranet and OPAC sides.
On Wed, May 14, 2008 at 2:43 PM, Jesse <pianohacker@gmail.com> wrote:
Eek. There's already a... plethora of modules in C4::. At the very least, we would be adding C4::ISBN, C4::OCLC and C4::LCCN. If we really need an OOP interface (seems like overkill for the simple reformatting this would be doing), we could have C4/Normalize.pm with subpackages in the file like C4::Normalize::ISBN, C4::Normalize::LCCN, etc.
It does make sense to put them all in a namespace like that to me, too. -A
I'm not a programmer, but am a Librarian... What about the 028 music/av item numbers(often ISBN's are not part of a video record as they may change) but often the producer number stays the same. I'll also mention a SuDoc number index, but I don't use them so will walk away now and hope nobody is throwing tomatoes - ... David Andrew Moore-5 wrote:
On Wed, May 14, 2008 at 2:43 PM, Jesse <pianohacker@gmail.com> wrote:
Eek. There's already a... plethora of modules in C4::. At the very least, we would be adding C4::ISBN, C4::OCLC and C4::LCCN. If we really need an OOP interface (seems like overkill for the simple reformatting this would be doing), we could have C4/Normalize.pm with subpackages in the file like C4::Normalize::ISBN, C4::Normalize::LCCN, etc.
It does make sense to put them all in a namespace like that to me, too.
-A _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
-- View this message in context: http://www.nabble.com/RFC-on-ISBN-sanitisations%2C-was%3A--Koha-patches---PA... Sent from the Koha - Dev mailing list archive at Nabble.com.
participants (6)
-
Andrew Moore -
David Schuster -
Galen Charlton -
Henri-Damien LAURENT -
Jesse -
MJ Ray