[Yazlist] support for solrmarc?

Adam Dickmeiss adam at indexdata.dk
Tue Mar 18 18:44:36 UTC 2014


On 03/18/2014 07:33 PM, Michael Lackhoff wrote:
> On 18.03.2014 18:40 Adam Dickmeiss wrote:
>
>>> &#1D; -> #29;  (record separator)
>>> &#1E; => #30;  (field separator)
>>> &#1F; => #31;  (subfield separator)
>> Boy that's ugly. And how's #29 then handled if it's NOT a control sequence?
> It is only a control sequence if followed by a ';'.
> In a Perl-application I need just one line to get perfectly valid iso2709:
> $in =~ s/#([0-9]{2});/chr($1)/eg;
> After this one-liner I can use any MARC-tool on the planet with it.
>
>> IMHO, using an element for that would have been more elegant.
> I have no influence on that and though it might not look like it, it
> really works well with data in the wild.
>
>>> <marc inputformat="solrmarc" outputformat="marcxml" outputcharset="utf-8"/>
>> In the conversion from solrmarc to marcxml there wouldn't be any illegal
>> characters.
>>
>> But the stylesheet to convert from solrmarc to marcxml would be a hairy
>> XSL transform indeed.
> A stylesheet would indeed be horrible. That is why I would like a
> variant of
> <marc inputformat="marc" outputformat="marcxml" outputcharset="utf-8"/>
> With the only difference that something like the regular expression
> above is applied first
>
>> Given such a stylesheet you'd use something like this to offer marcxml:
>>
>>            <retrieval syntax="xml" name="marcxml">
>>                   <backend syntax="xml">
>>                      <xslt stylesheet="solrmarc2marcxml.xsl"/>
>>                  </backend>
>>           </retrieval>
> Because such a stylesheet would be so difficult to write I want <marc>
> not <xslt> for the conversion.
> As I said it would be an almost trivial change (well I am not a C
> programmer but I hope it is). And to avoid any confusion or possible
> errors in normal iso2709 I came up with the suggestion of a new allowed
> inputformat for <marc>
> After all solrmarc is just another variant like 'marc', 'marcxml' or
> 'marc-json'
As a C programmer I would also prefer that over XSLT!

/ Adam
>
>> You could use record_transform to also offer marc21/usmarc in a marc
>> step (taking marcxml as input).
> That is exactly my intention: Offer all standard MARC variants from the
> one that is equivalent but is just this one-liner away from being
> useable as it is.
>
> -Michael
>
> _______________________________________________
> Yazlist mailing list
> Yazlist at lists.indexdata.dk
> http://lists.indexdata.dk/cgi-bin/mailman/listinfo/yazlist
>




More information about the Yazlist mailing list