(I'm copying this email exchange with Bryan Baldus to the list, so that anyone working in the Lint area is informed of our plans) Bryan wrote> One potential problem is with the previous character data Bryan wrote> being integrated into the _DATA_ section. Bryan wrote>...etc/specs.pl program that constructs the DATA section
Yes I was aware of this potential problem, but ignored it in my enthusiasm to get a Lint customisation working with an OOP design which would be easy to extend by adding more rules of a similar type. >From several points of view (to avoid the above problem, using loose rather than tight coupling with Lint.pm/modularity, making it easier for Perl4lib subscribers to see what's being done,...) it makes sense to takes the additional (AACR2-type) rules out of Lint2.pm and recreate them either: - in a Lint subclass (MyLint at present, but could be renamed Aacr) specialising the Lint methods; or - in a class/package parallel to Lint using the same methodology. I'm not sure which of these is the best solution, but I intend to start with the MyLint approach: * reddefining sub new in MyLint thereby overriding the (SUPERCLASS) Lint->new method, which will call Lint->new (cf MyLint->check_245) and add some of its own code (to read in the MyLint/AACR rules and add them to the $linter object's hash of rules per tag). I use Data::Dumper & print Dumper($linter) to debug this stage. * idem for sub check_record . This should preserve a strictly modular approach and nicely separate the Lint and 'AACR' rules. It would also allow more scope for flexible structuring of 'AACRetc' rules to cover a wide variety of validation checks: e.g. #TagId Scope Validate Expression Description/Warning #----- ----- ----- ---------- ------------------- 008 35-37 IsoLangCode Verify(ScopeValue) <ReturnValue> 043 SubFlds_abc Length 7 ... 245c PrvSubFld LastChars space/ ... 245 CurrFld LastChars . ... 856u CurrSubFld URLFound Verify(ScopeValue) <ReturnValue> 010-999 AllFields BadChars ,,|.. 010-999 AllFields LeadingSpaces More news later, Ian -----Original Message----- From: Bryan Baldus To: HAMILTON Ian (EAC) Sent: 19/11/2004 19:35 Subject: RE: Customising MARC::Lint & LintAdditions/ErrorChecks Thank you for the updates. I will probably begin looking at the Lint/Lintadditions modules this weekend, after having been occupied for the past few weeks on something else. In Lint2.pm: # <MODIF> to __DATA__: Control field definitions added (See Brian Baldus's LintAdditions.pm) should read: # <MODIF> to __DATA__: Control field definitions added (See Bryan Baldus's LintAdditions.pm) I like some of the changes you've made. One potential problem is with the previous character data being integrated into the _DATA_ section. This might need to be accounted for in the etc/specs.pl program that constructs the DATA section from the ecbdlist.html file (though the specs.pl states: "Also, the HTML file doesn't include the 841-88X tags, so those are hardcoded here," but I don't see where that is happening (in the version of the program included in MARC::Record 1.38). The lint.t test may need to be updated, as well. Talk to you later, Bryan Baldus Cataloger Quality Books Inc. The Best of America's Independent Presses [EMAIL PROTECTED] -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Friday, November 19, 2004 10:55 AM To: [EMAIL PROTECTED] Subject: RE: Customising MARC::Lint & LintAdditions/ErrorChecks Bryan, I've been doing a bit of work on incorporating some of your 260 & 230 checks into the Lint rule base. See the rules at the end of Lint2.pm + references to PrvChars in the rule parsing etc. >I would suggest you post about them on the Perl4Lib discussion list or contact Andy Lester Will do once I've tidied up some of the ugly bits ..; Bye Ian _____________________________________________ Ian Hamilton Library Systems Administrator European Commission - Directorate General for Education and Culture EAC D3 - Central Library Unit * +32-2-295.24.60 (direct phone) * +32-2-299.91.89 (fax) * http://europa.eu.int/eclas/
