Hi,
I have uploaded MARC::Record 2.0.7 and MARC::File::XML 1.0.5 to CPAN.
Both are minor bugfix and packaging update releases.
Here are the changes to MARC::Record:
2.0.7 Tue May 23 20:41:13 EDT 2017
[FIXES]
- RT#108123: clean up MANIFEST.SKIP
- GH#1: marcdump now prints
greetings to you all,
could you please give me a hint on how you treat some long waiting processes?
For example we are trying to upload a MARC file and then index it via a web
interface, but the whole procedure takes a lot, or we have no idea via dancer
front end how is it going, how could we b
Hi,
I have uploaded MARC::File::XML 1.0.3 to CPAN. This release fixes a
test failure on Strawberry Perl. Here is the changelog:
1.0.3 Thu Jan 23 05:02:52 UTC 2014
- fix t/external-entities.t to pass on Strawberry
Regards,
Galen
--
Galen Charlton
gmcha...@gmail.com
On Tue, Jan 21, 2014 at 12:38 PM, Galen Charlton wrote:
> Hi,
>
> I have uploaded [1] version 1.0.2 of MARC::File::XML. This is a
> security release that repairs an XML external entity (XXE)
> vulnerability. I recommend that all uses of MARC::File::XML upgrade
> promptly.
>
Hi,
I have uploaded [1] version 1.0.2 of MARC::File::XML. This is a
security release that repairs an XML external entity (XXE)
vulnerability. I recommend that all uses of MARC::File::XML upgrade
promptly.
Here is the change log entry:
1.0.2 Tue Jan 21 17:18:37 UTC 2014
- MARC::File
that there's a fair amount of clients of
MARC::File::XML that depended on an empty MARC::Record being returned when
given an empty record element. If your latest package is of 0.93, you may
want to hold off for a bit, as I have another release planned that will fix
a long-standing bug
Hi,
I have uploaded version 1.0 of MARC::File::XML to CPAN. Changes from
version 0.93 are:
1.0 Sun Feb 10 21:32:32 PST 2013
- Use XML::LibXML rather than XML::SAX to parse MARCXML records.
This offers a significant speed improvement for record parsing;
in some tests
;
}
If it works for you, great! And thanks to the original source, who I
would acknowledge, if I knew who it was.
JJ
-Original Message-
From: Reese, Terry [mailto:terry.re...@oregonstate.edu]
Sent: Thursday, January 12, 2012 12:03 PM
To: perl4lib@perl.org
Subject: MARC::Record / MAR
date them with MARCEdit.
...
>Looks like MARC::Record is doing its job correctly. Perhaps changing
>MARC::File::XML is in order.
MARC::File::USMARC includes a line in sub _next:
# remove illegal garbage that sometimes occurs between records
$usmarc =~ s/^[ \x00\x0a\x0d\x1a]+//;
If I r
nd 0D as
valid. However I hunted down a more official version of the map here:
http://lcweb2.loc.gov/diglib/codetables/42.html
And sure enough neither 0A or 0D is listed. Learn something new and all that.
Looks like MARC::Record is doing its job correctly. Perhaps changing
MARC::File::XML
AM
To: perl4lib@perl.org
Subject: perl4lib Digest 12 Jan 2012 16:31:25 - Issue 479
perl4lib Digest 12 Jan 2012 16:31:25 - Issue 479
Topics (messages 2952 through 2953):
MARC::Record / MARC::File::XML bug when fields contain newlines?
2952 by: arvinporthog.lycos.com
2953 by
On Wed, Jan 11, 2012 at 3:35 PM, arvinport...@lycos.com
wrote:
> I've been converting MARC XML records into USMARC and recently had a slew of
> bad records which MARCEdit reported as having invalid leaders. After a few
> days of puzzling over this and blaming it all on Unicode I noticed they wer
MARC21/slim";>
06965nam a2202005 u 4500
Theoretical and Technological
Aspects of Crystal Growth
(If your mail viewer mangles lines, there's a hard return (0D 0A) after the
word Technological in the 245)
Here is my test program which illustrates the pro
), then I can never use new_from_xml again in that
run of my script. Instead I get a "parser is already parsing" error.
I've made a small change to MARC::File::XML to work around this. In the
"decode" function, instead of:
$parser->parse_string( $text );
I now re-creat
> > However, when I try to generate MARCXML output with following code the
>> > Arabic characters gets corrupted:
>>
>> > $xml = MARC::File::XML->out( $file );
>> > my $record = MARC::Record->new();
>> > ...
>> > $xml->write( $rec
> > However, when I try to generate MARCXML output with following code the
> > Arabic characters gets corrupted:
>
> > $xml = MARC::File::XML->out( $file );
> > my $record = MARC::Record->new();
> > ...
> > $xml->write( $record );
> > ...
>
> However, when I try to generate MARCXML output with following code the
> Arabic characters gets corrupted:
> $xml = MARC::File::XML->out( $file );
> my $record = MARC::Record->new();
> ...
> $xml->write( $record );
> ...
> $xml->close();
> I'v
Hi,
I'm trying to create MARCXML records with data extracted from MySQL, in
which some of the records are in Arabic. I'm using MARC::Record (2.0.3),
MARC::File::XML (0.93) and DBD::mysql (4.012).
The output into ISO2709 shows the Arabic utf8 strings correctly with
following code snip
Hi,
I have uploaded version 0.93 of MARC::File::XML to CPAN. This is a
minor bugfix release:
0.93 Fri Feb 11 17:13:02 EST 2011
- When slurping MARCXML records (e.g., via MARC::Batch), can
now handle XML files that use a prefix
to refer to the http://www.loc.gov/MARC21
Hi,
First, when the patch is not applied, in both case, I have no error.
There are 2 cases:
1/ $ more /etc/perl/XML/SAX/ParserDetails.ini
[XML::SAX::PurePerl]
http://xml.org/sax/features/namespaces = 1
[XML::LibXML::SAX]
http://xml.org/sax/features/namespaces = 1
[XML::LibXML::SAX::Parser]
http
Hi,
On Tue, Dec 14, 2010 at 11:55 AM, Claire Hernandez
wrote:
> I had another issue, with another sax parser:
> Malformed UTF-8 character (unexpected end of string) in substitution
> (s///) at /usr/lib/perl5/XML/LibXML/Error.pm line 217.
> problem with :84 : :61: parser error : Input is not
ire;
From:
*Galen Charlton*
Date:
December 13, 2010 06:16
Subject:
Re: Problem with MARC::File::XML
Message ID:
aanlktinutec98fzq4dzz=t6hlvvyqe0nq4=uzepqp...@mail.gmail.com
<http://www.nntp.perl.org/group/perl.perl4lib/;msgid=aanlktinutec98fzq4dzz=t6hlvvyqe0nq4=uzepqp...@mail.gmail.com>
Hi,
On
Hi,
On Thu, Dec 2, 2010 at 5:09 AM, LAURENT Henri-Damien
wrote:
> we are currently trying to use MARC::File::XML on multi threaded
> decoding of records.
> We are encountering erratic error of Parsing.
> problem with :25 :
> not well-formed (invalid token) at line 32, column 2
Hi
we are currently trying to use MARC::File::XML on multi threaded
decoding of records.
We are encountering erratic error of Parsing.
problem with :25 :
not well-formed (invalid token) at line 32, column 27, byte 1216 at
/usr/lib/perl5/XML/Parser.pm line 187
http://www.w3.org/2001/XMLSchema
Any testing would be gratefully appreciated.
I've run some tests. Parsing 1000 MARCXML records gives me this result:
- with the current SAX handler: 8.21954107284546
- with new DOM method: 6.30712199211121
Thanks.
--
Frédéric
ementation even when using XML::ExpatNS as the SAX driver
(details of the testing can be found in two emails to koha-devel [2],
[3]). Since MARC::File::XML is presently geared towards parsing a
single record at a time, memory consumption shouldn't be much of an
issue.
Any testing woul
Hi,
On Tue, Mar 16, 2010 at 11:13 PM, Galen Charlton wrote:
> If there are no major objections, in a week's time I plan to make the
> CVS repo read-only and we'll move forward with Git.
I've now removed write access to the CVS repository, and will disable
CVS entirely once I see that people are
On Tue, Mar 16, 2010 at 11:13 PM, Galen Charlton wrote:
> If there are no major objections, in a week's time I plan to make the
> CVS repo read-only and we'll move forward with Git.
Hooray, thanks so much Galen! Sounds like a great plan moving forward.
//Ed
Hi,
On Tue, Jan 26, 2010 at 11:57 AM, Ed Summers wrote:
> I would argue for keeping stuff on sf.net ... and leapfrogging svn for
> git if we can.
To that end, I've enabled Git in the marcpm SourceForge project and
established a new repository which contains the history from the five
CVS modules
Hi,
On Tue, Jan 26, 2010 at 10:57 AM, Ed Summers wrote:
> I would argue for keeping stuff on sf.net ... and leapfrogging svn for
> git if we can.
Both suggestions would be perfectly fine with me. Bryan, for your
reference, TortoiseGit [1] seems to be a well-supported Windows client
for Git.
[1
I would argue for keeping stuff on sf.net ... and leapfrogging svn for
git if we can.
//Ed
On Tue, Jan 26, 2010 at 10:45 AM, Galen Charlton wrote:
> Hi,
>
> On Wed, Jul 22, 2009 at 7:53 PM, Dueber, William wrote:
>> Speaking for myself only, of course: Please, for the love of god, move away
>>
Hi,
On Wed, Jul 22, 2009 at 7:53 PM, Dueber, William wrote:
> Speaking for myself only, of course: Please, for the love of god, move away
> from CVS. Moving the code to a more modern VCS and a well-supported host. The
> least-painful move might be to SVN on Google Code.
Picking up on this thre
Hi,
I've uploaded 0.92 of MARC::File::XML to CPAN. The only changes since
0.91 are to POD and packaging, including adding back a copyright
statement in the README to satisfy Debian requirements. From the
change log:
0.92 Thu Jul 30 22:37:07 EDT 2009
- small documentation changes to
Hi,
I have uploaded version 0.91 of MARC::File::XML to CPAN. This release
also includes changes to its sibling module MARC:File::SAX. Changes
from 0.88 include:
0.91 Tue Jul 28 2009
- Nixing the stray space (always been there) in the schemaLocation
attribute for single-record
;
> Any objections to my pushing out 0.91 as a bugfix release? I've
> applied Bill's patch and addressed the one CPAN bug against 0.88. Any
> more patches still sitting on the floor?
>
> While I intend to go over MARC::File::XML with a fine-toothed comb
> some time in the
bug against 0.88. Any
more patches still sitting on the floor?
While I intend to go over MARC::File::XML with a fine-toothed comb
some time in the next few weeks, I figure that that the results will
be better targeted to a 1.0 release.
Regards,
Galen
Hi,
On Wed, Jul 22, 2009 at 5:04 PM, Dan Scott wrote:
> Was it decided that Bill's escaping output patch would be dropped? I
> don't see it in CVS yet.
I've committed Bill's patch and a test case based on the sample file
he sent. Thanks, Bill!
Regards,
Galen
2009/7/22 Galen Charlton :
> Hi,
>
> Nope, just haven't gotten around to pushing it. Soon, I promise!
>
> Funny you should mention CVS. I have a general question for the
> MARC/Perl hackers: Ed mentioned a while back moving from CVS to a more
> modern VCS such as Subversion or (my preference) Git
Speaking for myself only, of course: Please, for the love of god, move away
from CVS. Moving the code to a more modern VCS and a well-supported host. The
least-painful move might be to SVN on Google Code.
I'm pretty sure there's nothing but CVS available for OS9, though, so the
question has to
On Wednesday, July 22, 2009 4:10 PM, Galen Charlton
[galen.charl...@liblime.com] wrote:
>Funny you should mention CVS. I have a general question for the
MARC/Perl hackers: Ed mentioned a while back moving from CVS to a more
modern VCS such as Subversion or (my preference) Git. I'm willing to
do
Hi,
Nope, just haven't gotten around to pushing it. Soon, I promise!
Funny you should mention CVS. I have a general question for the
MARC/Perl hackers: Ed mentioned a while back moving from CVS to a more
modern VCS such as Subversion or (my preference) Git. I'm willing to
do the legwork to get
Was it decided that Bill's escaping output patch would be dropped? I
don't see it in CVS yet.
It would be nice to see the 0.91 release get pushed out the door, in
any case. 0.88 was a long time ago.
Dan
2009/4/14 Galen Charlton :
> Hi,
>
> On Tue, Apr 14, 2009 at 3:57 PM, Dan Scott wrote:
>> 20
Hi,
On Tue, Apr 14, 2009 at 3:57 PM, Dan Scott wrote:
> 2008/10/29 Bill Erickson :
> Is anyone planning on applying this patch? It would be a shame to drop
> it on the floor.
I'll take a look at it and apply it, unless somebody beats me to the
punch in the next day or two.
Regards,
Galen
--
G
2008/10/29 Bill Erickson :
> Hi all,
>
> I ran across some gnarly MARC data today, which contained, among other
> things, MARC codes of "<". I realized that Marc::File::XML outputs the MARC
> tags, codes, and indicators without escaping them. This results, in my
On Wed, Oct 29, 2008 at 5:01 PM, Dan Scott <[EMAIL PROTECTED]> wrote:
> 2008/10/29 Bill Erickson <[EMAIL PROTECTED]>:
> > Hi all,
> >
> > I ran across some gnarly MARC data today, which contained, among other
> > things, MARC codes of "<".
2008/10/29 Bill Erickson <[EMAIL PROTECTED]>:
> Hi all,
>
> I ran across some gnarly MARC data today, which contained, among other
> things, MARC codes of "<". I realized that Marc::File::XML outputs the MARC
> tags, codes, and indicators without escaping the
Hi all,
I ran across some gnarly MARC data today, which contained, among other
things, MARC codes of "<". I realized that Marc::File::XML outputs the MARC
tags, codes, and indicators without escaping them. This results, in my
case, in invalid XML like:
France
It seems re
Thanks to suggestions from Michael Kreyche & Bill Dueber, I have been able to
solve the problem with using the "file" command on my usmarc to marcxml
program.
It was the perl version. We were running on 5.8.7, which threw the error. Once
we upgraded to 5.8.8, program ran just fine.
I have a file of usmarc records which I want to read into a program and print
to a file as MARC xml. Here's my program so far:
#
#!/usr/local/bin/perl
use strict;
use warnings;
use MARC::Record;
use MARC::Batch;
use MARC::File::XML
Ed Summers a écrit :
It looks like you don't have an XML parser installed that supports the
features that M::F::X requires:
use XML::SAX qw(Namespaces Validation);
Try executing that, and see if you get a similar exception. FWIW
Namespace support is required for the version of MARC::File::SAX
It looks like you don't have an XML parser installed that supports the
features that M::F::X requires:
use XML::SAX qw(Namespaces Validation);
Try executing that, and see if you get a similar exception. FWIW
Namespace support is required for the version of MARC::File::SAX that
is in CVS since i
ems I have a problem with M::F::X :
[EMAIL PROTECTED] MARC-XML-0.88]# make test
PERL_DL_NONLAZY=1 /usr/bin/perl "-MExtUtils::Command::MM" "-e"
"test_harness(0, 'blib/lib', 'blib/arch')" t/*.t
t/batch
# Failed test 'use MARC
Hi all,
Just a quick announcement regarding an update of MARC::File::XML to version
0.88. From the Changelog:
0.88 Wed Nov 28 2007
- String test for subfield code to avoid dropping $0 (Galen Charlton)
0.88_1 Tue Oct 23 2007
- Fixed a typo in M::F::X that could be the origin of the
o exactly what you want. You can
either pass 'use' flags to M::F::X to set the default:
use MARC::File::XML ( BinaryEncoding => 'utf8', RecordFormat => 'UNIMARC' );
or, if you're reading the XML by hand one record at a time, you can
use new_from_xml (after
Doran, Michael D a écrit :
> Hi Henri,
>
>
>> Is there a reason why MARC::File::XML considers only a very
>> strict subset of utf-8 as valid ?
>>
>
> I would guess that it has to do with adhering to the MARC-21 repertoire of
> characters, so as to
Hi Henri,
> Is there a reason why MARC::File::XML considers only a very
> strict subset of utf-8 as valid ?
I would guess that it has to do with adhering to the MARC-21 repertoire of
characters, so as to facilitate the round-trip conversion between the MARC-8
and Unicode character set
part of a batch.
And it seems that trying to decode the marc record on its own leads to
problems.
Anyway, why is there a change in leader from 00154nx a2200073 4500
to 00162lbána2200073uel4500 ?
This leads to problem with MARC decoding.
Is there something to do about it ?
Coud MARC::File::
hi,
I have some problems with Marc::File::XML parser.
Take those two xml records.
Despite the fact that I agree that there are odd characters in some
subfields.
I am wondering why, since those characters are UTF8, MARC::File::XML
should drop them when parsing.
Is there a reason why MARC::File
On 8/19/07, Rina Ron <[EMAIL PROTECTED]> wrote:
> I got the error "wide character in print at IO/Handle.pm line 399" and
> solved it in a not nice way by using an object as a hash reference.
> Perhaps there is a better way.
I have updated CVS with code that checks the default output encoding
and s
Hi,
I have a problem with new_from_xml.
Here is my script :
my $record;
print $marcxml;
$record= MARC::Record->new_from_xml($marcxml,"UTF8","UNIMARC");
warn $record->as_xml;
Here is my data :
http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaL
I got the error "wide character in print at IO/Handle.pm line 399" and
solved it in a not nice way by using an object as a hash reference.
Perhaps there is a better way.
Here is what I have :
use MARC::File::XML ( BinaryEncoding => 'utf8', RecordFormat =>
'UNI
I was wondering why MARC::File::XML did not work with #2 file?!
1: a single record: http://www.loc.gov/standards/marcxml/Sandburg/sandburg.xml
2: a collection set: http://www.loc.gov/standards/marcxml/xml/collection.xml
The differences I noticed of the two are the prefix
I apologize, but I'm finding it hard to trace what exactly this script
is doing. I did take a look at the first failure and sure enough the
record leader says it's 463 bytes but the record itself is 464 bytes.
So a failure is warranted -- given the current behavior of
MARC::Record.
Perhaps dumbin
Joshua M. Ferraro a écrit :
- "Mike Rylander" <[EMAIL PROTECTED]> wrote:
CVS is updated with that now, and after anyone willing makes sure
it's not breaking anything I think we should release again.
Just updated and ran make test successfully. I'm happy to
roll a release today if there are
With MARC::Charset 0.96, MARC::Record 2.0.0, and MARC::File::XML from
CVS, I get failed tests for 7 out of 8 of Joshua's tests. Test STDIN
and STDOUT output attached.
Dan Scott
On 16/04/07, Joshua M. Ferraro <[EMAIL PROTECTED]> wrote:
- "Mike Rylander" <[EMAIL PRO
- "Mike Rylander" <[EMAIL PROTECTED]> wrote:
> CVS is updated with that now, and after anyone willing makes sure
> it's not breaking anything I think we should release again.
Just updated and ran make test successfully. I'm happy to
roll a release today if there are no objections.
This may be
On 4/13/07, Paul POULAIN <[EMAIL PROTECTED]> wrote:
Mike Rylander a écrit :
> On 4/13/07, Joshua M. Ferraro <[EMAIL PROTECTED]> wrote:
> $parser->{ Handler }{ toMARC8 } = (lc($format) =~ /^unimarc/o || (
> $enc && lc($enc) =~ /^utf-?8$/o )) ? 0 : 1;
>
mmm... I agree with you.
In fact, I think h
Mike Rylander a écrit :
On 4/13/07, Joshua M. Ferraro <[EMAIL PROTECTED]> wrote:
$parser->{ Handler }{ toMARC8 } = (lc($format) =~ /^unimarc/o || (
$enc && lc($enc) =~ /^utf-?8$/o )) ? 0 : 1;
mmm... I agree with you.
In fact, I think having a test that, if true make 0 as result and if
false
On 4/13/07, Joshua M. Ferraro <[EMAIL PROTECTED]> wrote:
Hi folks,
A new version of MARC::File::XML has been uploaded to CPAN. It's
a one character fix that solves a bug for UNIMARC users who don't
have MARC-8 encoded records. Thanks to Paul Poulain for pointing
it out.
Unf
Hi folks,
A new version of MARC::File::XML has been uploaded to CPAN. It's
a one character fix that solves a bug for UNIMARC users who don't
have MARC-8 encoded records. Thanks to Paul Poulain for pointing
it out.
Cheers,
--
Joshua Ferraro SUPPORT FOR OPEN-SOURC
As I have unimarc records, i'm not happy with that... so I have
investigated MARC::File::XML and found at line 448 :
> $parser->{ Handler }{ toMARC8 } = (lc($format) ne 'unimarc' && $enc
&& lc($enc) =~ /^utf-?8$/o) ? 0 : 1;
meaning that for "unimarc
On Fri, July 14, 2006 2:17 pm, Edward Summers wrote:
> 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 ...
I was commenting here about my concern raised by the findings of Paul
Poulain. I had no test of my own showing an
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:
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 t
On Jul 13, 2006, at 12:41 PM, Paul POULAIN wrote:
sometimes, I parse XML that contains invalid subfieldcode (like a
capital letter)
M::F::X definetly dies in this case.
MARC::Field seems to allow a subfield with a capital letter--as it
should since there really is no requirement that subfie
Hello all,
sometimes, I parse XML that contains invalid subfieldcode (like a
capital letter)
M::F::X definetly dies in this case.
Could it be possible to have an option that deals with invalid
subfieldcodes :
* die (actual behaviour)
* drop (drop the subfield)
* ignore (integrate the subfiel
On May 28, 2006, at 2:25 PM, Joshua Ferraro wrote:
Maybe a note somewhere in the MARC::File::XML documentation to point
these issues out would be useful. Also, it wouldn't be too bad to have
a few tests to make sure that the system's default SAX parser is
capable
of handling these c
Hi everyone,
Just providing an update on this issue. As you may recall, I've
been putting the MARC::Record suite, specifically MARC::File::XML
and MARC::Charset, through some fairly rigourous tests, including
a 'roundtrip' test, which converts the binary MARC-8 records to
MARCXML /
Hi everyone,
Thanks for all the help thusfar ... Things are running much smoother
since I installed XML::SAX::Expat. However, I'm still having a
problem I haven't been able to work around. I have the following
batch of 5 records:
http://liblime.com/public/several.mrc
They don't throw any errors
On Mon, 20 Mar 2006 10:54:08 -0500
"Mike Rylander" <[EMAIL PROTECTED]> wrote:
> Except that Perl doesn't know that the data is already UTF8 ... which
> is the problem. [...]
You're completely right, I understand the difference. We made UTF8 work
from MySQL bu we didn't tried to work on data comin
all PerlIO channels.
There really isn't any way around this if you want to claim real UTF8
support and be able to use components that really do support UTF8
natively, like MARC::File::XML and MARC::Record.
It's unfortunate that the DBD::mysql people won't fix their module,
but
Hello Mike,
I'll answer to the second question, since I worked with Paul on
Perl/MySQL and UTF-8...
On Mon, 20 Mar 2006 09:59:32 -0500
"Mike Rylander" <[EMAIL PROTECTED]> wrote:
> Are you using decode_utf8($mysql_string) to let Perl know that the
> database is UTF8 encoded? IIRC, MySQL doesn't
Mike Rylander a écrit :
On 3/20/06, Paul POULAIN <[EMAIL PROTECTED]> wrote:
Mike Rylander a écrit :
I tested with the record you sent Ed and me, and everything seems to
work for me ...
As you can see, I tested several variants of the UNIMARC flag, and
even tested not sending the encoding to n
On 3/20/06, Paul POULAIN <[EMAIL PROTECTED]> wrote:
> Mike Rylander a écrit :
> > I tested with the record you sent Ed and me, and everything seems to
> > work for me ...
> > As you can see, I tested several variants of the UNIMARC flag, and
> > even tested not sending the encoding to new_from_xml(
Mike Rylander a écrit :
I tested with the record you sent Ed and me, and everything seems to
work for me ...
As you can see, I tested several variants of the UNIMARC flag, and
even tested not sending the encoding to new_from_xml() ... it all
seems to work for me, and I'm not sure what problems yo
I tested with the record you sent Ed and me, and everything seems to
work for me ... comparing the preprocessed XML with a copy that I
round-tripped through MARC::Record and MARC::File::XML, they look the
same. Here's my little test script (unimarc-te
nstall
I updated MARC::record (2.000), MARC::Charset (0.920) and
MARC::File::xml (0.810 ???) from sourceforge.
I tested with a unimarc xml file (that I've send to you by pm), without
change.
what did I make wrong ?
--
Paul POULAIN et Henri Damien LAURENT
Consultants indépendants
en logi
Mea culpa ... read on. :)
On 3/16/06, Mike Rylander <[EMAIL PROTECTED]> wrote:
> I've updated the cvs for MARC::File::XML with what I described below,
> with one caveat. The one difference from what I was planning is that,
> because as_xml() is generated by MARC::Record,
On 3/16/06, Mike Rylander <[EMAIL PROTECTED]> wrote:
> Will some brave soul please test this with some UNIMARC records and
> let me know how it goes?
Yes please, add the test to the test suite if possible Joshua and Paul.
miker_++
//Ed
I've updated the cvs for MARC::File::XML with what I described below,
with one caveat. The one difference from what I was planning is that,
because as_xml() is generated by MARC::Record, I can't give it new
parameters. To test exporting to XML you'll need to set the record
fo
I've been attempting to beat the MARC::File::XML stuff into a usable
shape as of late, so I'm going to take a stab at fixing this. There
will be some limitations (at first) as to what encodings we'll accept
for UNIMARC records, but I'll cover the cases that I know about (and
rc_abrege.pdf, page
8 for 100$a)
BIG PROBLEM :
MARC::File::XML only checks for position 9, thinking the XML is
necessary a marc21 file.
I think (& joshua agrees) we will have to hack MARC::File::XML to
solve this problem.
We have 2 solutions :
* add a test to define wether we are UNIMARC or M
Hello all,
Still working on UNICODE in Koha.
We are stuck with a not-so-nice problem. (Many many thanks to the
librarians that wrote marc21 and unimarc standards...)
I explain :
yesterday :
joshua "the new marc::file::xml works fine with utf8 now".
me : "Great ! i'll g
On 1/10/06, Paul POULAIN <[EMAIL PROTECTED]> wrote:
> Repeat after me : Ed Summers is the best Perl coder for librarians !
Oh shucks, thanks, I *really* wish that was true. The reality is that
I wrote that module and was familiar with one of its limitations.
The real people who should be praised
I should have mentioned that MARC::File::XML uses XML::SAX for XML
parsing. XML::SAX can use a variety of backend XML parsers, but I
believe by default it will use the XML::SAX::PurePerl parser if it
can't find any other ones installed, which is exceptionally slow.
I recommend taking a lo
On 1/9/06, Paul POULAIN <[EMAIL PROTECTED]> wrote:
> what am I doing wrong ?
Using Perl? :-)
Seriously though, i'd be interested in DProf [1] output from your
program if you have the energy.
//Ed
[1] http://search.cpan.org/~ilyaz/DProf-19990108/DProf.pm
Hi,
I begin using MARC::File::XML in Koha, to read XML records and transform
them in MARC::Record.
I tried some perfs and it seems they are really poor.
something like :
* reading a line in mySQL (1 DB line, indexed, so really fast, contains
a MARCXML field)
* create a MARC::Record with my
Ed Summers a écrit :
I'm curious what people would find to be the best default behavior for
MARC::File::XML when it creates a MARC::Record object from XML. Should
the character encoding by default by transposed from UTF-8 to MARC-8?
Or should it be left as UTF-8?
maybe a new_from_xml
I'm curious what people would find to be the best default behavior for
MARC::File::XML when it creates a MARC::Record object from XML. Should
the character encoding by default by transposed from UTF-8 to MARC-8?
Or should it be left as UTF-8?
//Ed
at app's
> character set was apparently Unicode (UTF-8) and so E5 and F2 were
> replaced by U+FFFD. That's the long way of saying that the patch should
> work fine in his case. :-)
>
I understand. It wasn't that I was trying to solve that particular
problem, it just go
100 matches
Mail list logo
