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 of an ironic statement, considering a regular, constant
> complaint on several library-related mailing lists I'm on is that
> emails are coming in "garbled" or need to be sent again in "plain
> text".   Without fail it's because the person is using a client that
> won't or can't deal with Base64.  Yes, silly this day and age.

Well, yeah, of course the receiving party could be broken, but there's 
definitely all the information and rules it could use to decode the data.

> Perhaps I'm just jaded from working into libraries for too long but
> your examples assume some logical consistent control through the
> process of dealing with MARC data.

Not really, just some consistency in working with XML.

> while later they start raising alarms because of either:  they see the
> markup in the record and wonder what's happening and how to remove it
> or one of those tools treats that area as text, another as xml
> content, and somewhere along the way it gets messed up.

I failed to make the statement that I definitely don't support adding 
HTML to MARC records (unless at least a clean and backwards-compatible 
way to do that is devised). My point was just that the transport 
mechanism is irrelevant.

> database that was put there by the original MARC.  The code is
> horribly setup and hackish and certain fields do not bother to escape
> what it's retrieving from the record.  You then go to import to your
> new ILS, which validates the MARCXML.  It of course now croaks because
> you have something like
> <marc:subfield code="a"><div class="foo">pretty</div>.

You're screwed then. You don't need embedded HTML to break it. For 
instance a simple < ("less than") character in a field would do. This is 
an example of very broken XML creation. I've done it myself too, but 
fixed it asap to avoid more embarrassment. All this, however, is not a 
useful argument in the HTML in MARC records debate.

> Would you count on having someone on the staff who will be able to fix
> those MARCXML files?  Or did you have someone like that and they
> burned out?  How long before the support contract on your old ILS
> forces you to abandon it?

Ok, this is drifting off-topic, but if you have a way to get the 
original MARC records in ISO2709 format (or any other non-broken 
format), it's a very simple task to convert them to valid MARCXML.

> I mainly sent out this email though because I don't think the folks
> who have been pointing out issues are confused.  It's not that we
> don't understand that it should be able to "round-trip" or that we
> haven't played around with html in other data formats.  I think we've
> used enough software in the library would to not trust all the layers
> will work as they should.

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 
receiving party can get the data intact.

--Ere