Re: MARC::* concern (Re: MARC::File::XML suggestion)

This is all fine, but lets talk in unit tests for MARC::Record if we  
can. They will make plain what the actual behavior is, and will let  
us talk about what the preferred behavior could be. Sorry to be so  
short, but there's only so much time in the day.

//Ed

On Jul 13, 2006, at 2:55 PM, Thomas Dukleth wrote:

> The MARC record management libraries need to allow management of the
> legacy records we actually have and the records that existing systems
> currently use.
>
> Some problems that MARC record management libraries need to manage:
>
> 1.  CHARACTER VARIANCE FOR FIELD CODES.
>
> Large union catalogue systems such as RLIN and OCLC have already  
> specified
> almost every numeric  MARC 21 local use field for their own purposes.
> Canadian local use fields for equivalence or cross-reference between
> languages are part of the MARC 21 standard even if they are only  
> used in
> Canada.  RLIN itself has specified so many local use fields that  
> they have
> added field codes with letters instead of only numbers to provide more
> local use fields for special purposes of theirs.
>
> Local system use of field codes that are not strictly numeric would  
> seem
> to be a reasonable solution to the problem of too many potential  
> reserved
> uses of local use fields.  Such usage would allow local use fields  
> which
> do not interfere with the established local use.fields of popular  
> union
> catalogue systems.
>
>
> 1.1.  NO PROBLEMS WITH RECORD MANAGEMENT MODULES?
>
> I have not observed problems with field codes containing non-numeric
> characters using MARC::Record or MARC::File::XML.  However, I have not
> tested extensively and want to be certain that no problems would  
> not arise
> from such usage in future.
>
>
> 2.  CHARACTER VARIENCE FOR SUBFIELD CODES.
>
> On Thu, July 13, 2006 4:41 pm, Paul POULAIN wrote:
>> Could it be possible to have an option that deals with invalid
>> subfieldcodes :
>
> Whether valid or not, real systems use punctuation symbols to  
> designate
> subfields so as not to interfere with standard usage.  No, $9 is not
> always enough.  Use of $% and $@ is widespread.
>
> RLIN uses $% to store the control number of a linked authority record.
> UNIMARC has provided $3 for the same purpose.  The problem of how  
> to match
> bibliographic records to authority records has been left to system
> designers for MARC 21.
>
> Punctuation symbols may be sufficiently numerous for some purposes  
> but I
> can certainly imagine a case in a system where actually using capital
> letters in addition to the standard lowercase letters would be very
> helpful.
>
>
> 2.1.  PROBLEMS WITH RECORD MANAGEMENT MODULES.
>
>
> I have not tested this but expected that at least some punctuation  
> might
> be liable to be a problem for some record management modules.  Paul
> Poulain reports this as a problem for MARC::File::XML.  I believe  
> his case
> had problems with $> as a subfield in addition to possibly capital
> letters.
>
> On Thu, July 13, 2006 4:41 pm, Paul POULAIN wrote:
>> * die (actual behaviour)
>
> Maybe this would not be a problem for some punctuation, but I would  
> like
> to be certain that it would not to be a problem for any punctuation  
> nor
> for capital letters either.
>
>
> 3.  SYSTEMS ANSWERING REAL NEEDS.
>
> Systems are designed to answer real needs in the real world.  Of  
> course,
> extensions to standard usage should sometimes be filtered out to
> facilitate maximally interoperable record exchange when exported  
> for use
> outside the system for which the extensions were created.  However,  
> the
> recipient of an unfiltered record may not have the option of  
> choosing a
> filtered record if only unfiltered records are available.  The record
> recipient's system has to cope with available records or not use them.
>
> If system designers are adding elements to MARC, which extend the  
> standard
> without conflicting with the standard; then the libraries used to  
> manage
> the records must support such records.
>
>
> Thomas Dukleth
> Agogme
> 109 E 9th Street, 3D
> New York, NY  10003
> USA
> http://www.agogme.com
> 212-674-3783
>
>