On Wed, Nov 19, 2003 at 09:16:20AM +0100, Tajoli Zeno wrote: > Hi to all, > > At 01.52 19/11/03, Morbus Iff wrote: > [...] > >Is that something anyone would be interested in? I suspect there are a huge > >amount of problems with the approach (most prominently that the idea of > >using tag numbers was to reduce typing in the first place), but has anyone > >ever > >had some non-MARC-expert intern try to modify some code and screw it up? > >Would "English"'d methods like this be helpful? > > > In fact I don't subscribe this type of changes. > Why ? > Because they hard coded in the module the USMARC/MARC21 standard. > > There different flouvers of MARC, the Library of Congress mantains USMARC > <now MARC21>. > For example I use Unimarc, mantained from IFLA. > > A concise Unimarc <until update 4> is avaible from: > http://www.ifla.org/VI/3/p1996-1/concise2.pdf > A full Unimarc <until update 3> is avaible from: > http://www.ifla.org/VI/3/p1996-1/sec-uni.htm > > The differences between MARC21 and Unimarc are many; a good documentation > is avaible from: > http://www.loc.gov/marc/unimarctomarc21.html <update to August 2001>. > From example there are differences also in the Record Leader !!.
Morbus Iff will correct me if I'm wrong, but I don't think the changes he proposed were to replace the full field/subfield/indicator interface available through MARC::Record. The MARC::Simple module would be an optional adjunct to the other MARC:: modules. It would not change the way MARC::Record functions. Your post does suggest the need perhaps to be able to qualify MARC::Simple with a particular flavor. It does also illustrate some of the extensibility problems arising from the use of field- and subfield-specific methods with English'd names. Chuck