I've been sending this to the wrong address, please accept apologies for
delay/reposting if I missed it going out.

On Mon, 8 May 2000, Bernhard Eversberg wrote:

> Robert Gardner informed us about a MARC-to-XML tool.

Thanks, but I use Robert to get away from the more sundry and generic uses
of "John" :-)

> This, as well as LC's SGML tools
>    http://lcweb.loc.gov/marc/marcdtd/marcdtdback.html
> is all very sensible, but is presumably not what was envisioned earlier
in
> this list in the MARC vs. XML debate. Both these concepts essentially

true, I was travelling then, and am typing with braces on now due to
workload, so didn't join in . . .but see below . . .

:-(

> preserve the MARC tagging and just put a different wrapper around stuff.
> By and large, they does away with the awkward "record directory"
structure,
> but not much more. Whereas in the aforementioned debate, the idea was
that

yup

> one might develop something radically new and significantly easier to
> handle. That would require an approach on the contents level rather than
> the structural level only. Or am I mistaken?

>From what I wrote, no--you're not mistaken.  However, to take the point,
I would argue that XML is a proper portal to such a "contents level"
solution of which you speak.  Such a solution, to truly be a solution,
will take a while.  During that time, the cache of XML continues to
evolve, and the support (cf. Intel is now making XML-aware _hardware_ !!)
are solid, so XML as a better set of wrappers insures that when the
contents level camelot is built, there will be a plethora of tools for
conversion and, in the meantime, the rich MARC data can partake of XML
assets, and the XML information wave can partake of MARC in turn.

hopefully, i'm a little clearer this time, but hard to type with thise
darn braces.