Yeah, if I was writing code to display MARC, I think the _right_ thing to do would be to escape anything I was displaying, because I'd assume it was NOT html, but might have < or > chars in it, etc.
I don't think HTML tags belong in MARC, that seems like a bad idea to me. Unless there was a way to encode that a given field was html -- but even THAT seems like a bad idea to me. What is html display tags doing in marc data? That's not what it's for. One example of a decent way to put things that can be _transformed_ into html in MARC is the 856$y subfield for specifying a display label. If you can find a way to put the url to an image in a particular subfield of your MFHD designated (even locally) for such, that would be the right way to do it -- but odds are you can't get your OPAC to do anything with that anyway. But trying to put weird inappropriate things in MARC in order to cater to the idiosyncratic disfunctional presentation software you happen to be stuck with -- leads to bad unpredictable marc you're going to regret later, as your data WILL outlast the particular software you happen to be using at present to display it. Jonathan ________________________________________ From: Code for Libraries [[email protected]] On Behalf Of Walter Lewis [[email protected]] Sent: Sunday, June 21, 2009 4:47 PM To: [email protected] 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 "<img>" 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 > reasoning behind the opinions), both pro and con. > One of the things I found in some specific instances where I was generating Marc-like records on the fly from records that could have embedded HTML (i.e. MARBI marc community output) was that a variety of the targets that could read the data didn't know what to do with the <tags> and escaped them before passing them to the web client. 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 ... :) Walter Lewis
