I agree with Ere that XML isn't the real issue here, in understanding
why embedding HTML in MARC is nevertheless something to be avoided if at
all possible. :)
Ere Maijala wrote:
Jon Gorman wrote:
You could substitute XML with e.g. Base64 encoding if it makes thinking
about this stuff eas
de for Libraries [mailto:code4...@listserv.nd.edu] On
>> Behalf Of Tim Hodson
>> Sent: Thursday, June 25, 2009 3:23 PM
>> To: CODE4LIB@LISTSERV.ND.EDU
>> Subject: Re: [CODE4LIB] HTML mark-up in MARC records
>>
>> Michael,
>>
>> A lot of the discussio
Ere Maijala wrote:
And my response was to Jonathan simply trying to state that encoding the
stuff in XML doesn't make a difference. I agree with you that there are
interoperability issues, but there are also examples in the library
world where stuff just works even when XML is involved, and the
No argument here. Perhaps I misunderstood your previous message as it
was related to Mark's message about OAI-PMH etc.
--Ere
Jonathan Rochkind wrote:
But here's my point.
There is no way for a consumer of MARC records to know if the MARC
records contain HTML or not. If a downstream consumer
Jon Gorman wrote:
You could substitute XML with e.g. Base64 encoding if it makes thinking
about this stuff easier. For instance email clients often send binary files
in Base64, but it doesn't mean the file is ruined, as the receiving email
client can decode it back to the original binary.
A bit
CODE4LIB@LISTSERV.ND.EDU
Subject: Re: [CODE4LIB] HTML mark-up in MARC records
Email Disclaimer: http://www.co.marin.ca.us/nav/misc/EmailDisclaimer.cfm
-688-1926 mobile
# do...@uta.edu
# http://rocky.uta.edu/doran/
> -Original Message-
> From: Code for Libraries [mailto:code4...@listserv.nd.edu] On
> Behalf Of Tim Hodson
> Sent: Thursday, June 25, 2009 3:23 PM
> To: CODE4LIB@LISTSERV.ND.EDU
> Subject: Re: [CODE4LIB]
Michael,
A lot of the discussion so far seems to have missed the opportunity to
find out exactly what you are hoping to accomplish. (unless I missed
that post :) ). And to perhaps suggest alternative ways of doing that.
My first question is: What is the image an image of?
This is shortly followe
But here's my point.
There is no way for a consumer of MARC records to know if the MARC
records contain HTML or not. If a downstream consumer wants to display
MARC in an html environment, the consumer can either assume they contain
html, and then end up displaying MARC _wrong_ if it has has h
> You could substitute XML with e.g. Base64 encoding if it makes thinking
> about this stuff easier. For instance email clients often send binary files
> in Base64, but it doesn't mean the file is ruined, as the receiving email
> client can decode it back to the original binary.
A bit of an ironic
Jonathan Rochkind wrote:
Ere Maijala wrote:
That shouldn't be a problem as any sane OAI-PMH provider, unAPI or ATOM
serializer would escape the contents. Things that resemble HTML tags
could be present in MARC records without any HTML-in-MARC too.
Sure, and then, if you have html tags in you
Ere Maijala wrote:
That shouldn't be a problem as any sane OAI-PMH provider, unAPI or ATOM
serializer would escape the contents. Things that resemble HTML tags
could be present in MARC records without any HTML-in-MARC too.
Sure, and then, if you have html tags in your marc, that system doing
Mark Jordan wrote:
- "Walter Lewis" wrote:
In
short, consider the downstream partners who may try and render the
HTML and what interfaces they are using. Not everyone views the
record via a browser ... :)
One downstream client that embedded HTML-in-MARC will almost
certainly cause gri
I'm with ecorrado on this one, with the caveat that if you insist on putting
a specific markup into your MARC -- and, boy, do the ROI analysis *very*
carefully before jumping in -- you should probably stick the marked-up data
in as a copy in a 9xx or somesuch. Leave the original value alone, and
mi
I agree with everyone that has said embedding HTML in MARC records is
bad in theory, but sometimes you might not have a better option to serve
your community. I say do what you need to do to get your users to where
they have to go until we have better systems. The one caveat I'd point
out if yo
There are things you'd want to do with data in a MARC record _other_
than display it in HTML. Maybe you want to send it to someone in email,
or a txt message. Embedding html in your marc is going to make this more
difficult than it should be.
Alexander Johannesen wrote:
Hiya,
I guess I'm the
On Tue, Jun 23, 2009 at 9:39 AM, Casey Bisson wrote:
> The mistake here is presuming that (X)HTML coded data isn't (or can't be)
> data.
>
I think it's a greater mistake to assume that it will be.
We are talking about putting semantics into a structured data source (by
people who are trained in
The mistake here is presuming that (X)HTML coded data isn't (or can't
be) data.
On Jun 23, 2009, at 12:22 AM, Roy Tennant wrote:
If we've learned anything at all, it should be to not mix
presentation with data.
On 6/22/09 6/22/09 4:17 PM, "Alexander Johannesen"
wrote:
> Even *if* HTML in MARC records probably is a bad idea.
Yes, it's such a bad idea it's hard to know where to begin. I'd like to
thank Kyle Banerjee for bringing up ISBD. This is like the HTML of the 60's
in the sense that now MARC is s
> Don't think for a second that purity of the data format in any shape
> or form is the definition of its usefulness.
We'd be screwed if that was the case. ISBD punctuation has been in the
MARC record from the very beginning. Theoretically, it should be
totally unnecessary since the data is alread
Hiya,
I guess I'm the one who's got to step up to the self-slaughtering
altar, but the fact that a lot of our systems break or don't know how
to handle HTML is despicable. I'm sure you guys are familiar with RSS
/ Atom, and because in there we *expect* HTML and therefore make sure
our back-ends ca
On Jun 22, 2009, at 5:53 PM, Cloutman, David wrote:
From the perspective of a programmer, rather than a cataloguer, my
opinion is firmly no, HTML does not belong in your MARC records.
In application development, general best practice is to separate
information systems into layers, splitting
L, you are much better off
leaving the HTML out of your MARC, and allowing the application to generate
tags.
-Original Message-
From: Code for Libraries on behalf of Doran, Michael D
Sent: Sun 6/21/2009 1:12 PM
To: CODE4LIB@LISTSERV.ND.EDU
Subject: [CODE4LIB] HTML mark-up in MARC records
-Original Message-
From: Code for Libraries [mailto:code4...@listserv.nd.edu]on Behalf Of
Doran, Michael D
Sent: Sunday, June 21, 2009 5:09 PM
To: CODE4LIB@LISTSERV.ND.EDU
Subject: Re: [CODE4LIB] HTML mark-up in MARC records
Hi Stuart,
> A couple of quick questions:
I'd be glad t
- "Walter Lewis" wrote:
In
> short, consider the downstream partners who may try and render the
> HTML
> and what interfaces they are using. Not everyone views the record via
> a
> browser ... :)
>
One downstream client that embedded HTML-in-MARC will almost certainly cause
grief for
stuart yeates
[stuart.yea...@vuw.ac.nz]
Sent: Sunday, June 21, 2009 4:05 PM
To: CODE4LIB@LISTSERV.ND.EDU
Subject: Re: [CODE4LIB] HTML mark-up in MARC records
Doran, Michael D wrote:
> Is anybody else embedding HTML mark-up code in MARC records [1]? We're
> currently including an ""
Doran, Michael D wrote:
Is anybody else embedding HTML mark-up code in MARC records [1]? We're currently including an "" tag in some MARC Holdings records in the 856z [2]. I'm inclined to think that HTML mark-up does not belong anywhere in MARC records, but am looking for other opinions (prefer
at present to display it.
Jonathan
From: Code for Libraries [code4...@listserv.nd.edu] On Behalf Of Walter Lewis
[lew...@hhpl.on.ca]
Sent: Sunday, June 21, 2009 4:47 PM
To: CODE4LIB@LISTSERV.ND.EDU
Subject: Re: [CODE4LIB] HTML mark-up in MARC records
Doran, Michael D wrote:
&
]
Sent: Sunday, June 21, 2009 3:47 PM
To: CODE4LIB@LISTSERV.ND.EDU
Subject: Re: [CODE4LIB] HTML mark-up in MARC records
Doran, Michael D wrote:
> Is anybody else embedding HTML mark-up code in MARC records [1]? We're
> currently including an "" tag in some MARC Holdings reco
I strongly oppose using any HTML mark-up in MARC records - this should
be the domain of the OPAC to render things appropriately. URIs for
images are fine, but is subfield z appropriate as well? I'd be
inclined to use a subfield 9 since it's purposely designed for local
use.
Mark A. Matienzo
Applic
Doran, Michael D wrote:
Is anybody else embedding HTML mark-up code in MARC records [1]? We're currently including an "" tag in some MARC Holdings records in the 856z [2]. I'm inclined to think that HTML mark-up does not belong anywhere in MARC records, but am looking for other opinions (prefer
Is anybody else embedding HTML mark-up code in MARC records [1]? We're
currently including an "" tag in some MARC Holdings records in the 856z
[2]. I'm inclined to think that HTML mark-up does not belong anywhere in MARC
records, but am looking for other opinions (preferably with the reasonin
32 matches
Mail list logo
