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

Reply via email to