 |
 |
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 html special chars like < or > but does not have html. Or it can assume it does _not_have HTML, and end up displaying escaped html tags to the user if it really DOES have html. This really applies no matter what presentation format the downstream consumer wants to display in. Plain text? Assume it is html, and strip out html tags, potentially accidentally stripping out actual information if it wasn't html but contained html special chars. Or assume it's not html and just plain text, and just display it, and show the user html tags. There's no way for a downstream consumer of MARC records to know if data is in html or just plain text. In general, I think this is becuase the assumption is it's always just plain text. If you start putting html in there, there's no way for a downstream consumer to predict whether it's going to be html or not, because that's not part of the MARC standard to advertise that, so there's no way for a downstream consumer to reliably display it correctly. You've put html in counting on your current local system being specifically configured to expect html in certain MARC fields. Fine. But as soon as you start distributing that MARC to downstream consumers, you've made things awfully confusing and unpredictable. Jonathan Ere Maijala wrote: > 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 your marc, that system doing >> the re-use is going to present content to users with escaped HTML in it, >> which isn't desirable either! >> > > How the content is stored in the transport format is separate from how > it is used. Whatever the re-using system does is not related to how the > data was transferred to it. If it extracts the stuff from the XML, it > will of course unescape the content, but what happens after that is up > to the system and unrelated to the transport mechanism. So here is an > example of the whole process: > > MARC with embedded HTML > -> > OAI-PMH provider escapes the MARC in some XML format > -> > OAI-PMH harvester (the re-using system) unescapes the data from the XML > format > -> > Something is done with the data > > It's the same as if the source system stores the data internally in > MARCXML. The content must be escaped so that it can be stored in MARCXML > and doesn't mess up the markup, but when the uses the data e.g. for > display, it's first retrieved from XML and unescaped, and massaged to > the desired display format only after that. If you use DOM to do the XML > manipulation, all this will happen automatically. You just write and > read strings and DOM manipulation takes care of escaping and unescaping. > > 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. > > --Ere >