<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	>
<channel>
	<title>Comments on: The Soul-sucking vacuum that is EAD</title>
	<atom:link href="http://dilettantes.code4lib.org/2006/12/the-soul-sucking-vacuum-that-is-ead/feed/" rel="self" type="application/rss+xml" />
	<link>http://dilettantes.code4lib.org/2006/12/the-soul-sucking-vacuum-that-is-ead/</link>
	<description></description>
	<pubDate>Thu, 04 Dec 2008 02:44:38 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.7-hemorrhage</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: mark matienzo</title>
		<link>http://dilettantes.code4lib.org/2006/12/the-soul-sucking-vacuum-that-is-ead/#comment-4946</link>
		<dc:creator>mark matienzo</dc:creator>
		<pubDate>Sat, 30 Dec 2006 14:31:39 +0000</pubDate>
		<guid isPermaLink="false">http://dilettantes.code4lib.org/2006/12/20/the-soul-sucking-vacuum-that-is-ead/#comment-4946</guid>
		<description>The menus sound neat - can you tell me more about those? (I don't think I've seen finding aids do anything like that.)

I think archivists run to XSLT before anything else because it's seemingly simple (to them). Most archivists want two things in terms of finding aids. First, they want them to look reasonably good, which, in the past - and sometimes currently, too - meant preserving the look of paper finding aids. This opinion is starting to fade and I hope it does. The second thing they want is them to be indexed and searchable locally OR via Google. 

I pretty much agree with your view about XSLT. One of the biggest frustrations I have at work is the overwhelming opinion that instead of doing things dynamically we should set them up as processes that run on intervals. I'm not even talking nightly or weekly cron jobs - I'm talking about running things manually every six months!

Also, if you're stuck with the EAD tar baby some more, I suggest signing up for the EAD listserv if you haven't already.</description>
		<content:encoded><![CDATA[<p>The menus sound neat - can you tell me more about those? (I don&#8217;t think I&#8217;ve seen finding aids do anything like that.)</p>
<p>I think archivists run to XSLT before anything else because it&#8217;s seemingly simple (to them). Most archivists want two things in terms of finding aids. First, they want them to look reasonably good, which, in the past - and sometimes currently, too - meant preserving the look of paper finding aids. This opinion is starting to fade and I hope it does. The second thing they want is them to be indexed and searchable locally OR via Google. </p>
<p>I pretty much agree with your view about XSLT. One of the biggest frustrations I have at work is the overwhelming opinion that instead of doing things dynamically we should set them up as processes that run on intervals. I&#8217;m not even talking nightly or weekly cron jobs - I&#8217;m talking about running things manually every six months!</p>
<p>Also, if you&#8217;re stuck with the EAD tar baby some more, I suggest signing up for the EAD listserv if you haven&#8217;t already.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ross</title>
		<link>http://dilettantes.code4lib.org/2006/12/the-soul-sucking-vacuum-that-is-ead/#comment-4910</link>
		<dc:creator>Ross</dc:creator>
		<pubDate>Fri, 29 Dec 2006 17:59:28 +0000</pubDate>
		<guid isPermaLink="false">http://dilettantes.code4lib.org/2006/12/20/the-soul-sucking-vacuum-that-is-ead/#comment-4910</guid>
		<description>Mark, the problems I was having were mostly due to my ignorance of XSLT coupled with the complexity of the design archives wanted for the detailed description.

One of things I want the finding aid to do is contextually display menus for subject headings, personal names, corporate names, citations, etc.  I &lt;em&gt;suppose&lt;/em&gt; this would be possible with XSLT, but, why?  

In my (admittedly) narrow view, XSLT is best for taking input and producing some sort of static output for it.  But, again, I plead ignorance on all this.</description>
		<content:encoded><![CDATA[<p>Mark, the problems I was having were mostly due to my ignorance of XSLT coupled with the complexity of the design archives wanted for the detailed description.</p>
<p>One of things I want the finding aid to do is contextually display menus for subject headings, personal names, corporate names, citations, etc.  I <em>suppose</em> this would be possible with XSLT, but, why?  </p>
<p>In my (admittedly) narrow view, XSLT is best for taking input and producing some sort of static output for it.  But, again, I plead ignorance on all this.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: mark matienzo</title>
		<link>http://dilettantes.code4lib.org/2006/12/the-soul-sucking-vacuum-that-is-ead/#comment-4863</link>
		<dc:creator>mark matienzo</dc:creator>
		<pubDate>Fri, 29 Dec 2006 00:33:18 +0000</pubDate>
		<guid isPermaLink="false">http://dilettantes.code4lib.org/2006/12/20/the-soul-sucking-vacuum-that-is-ead/#comment-4863</guid>
		<description>Hi Ross - just started reading your blog recently. Can you tell me more about the problems you were having with the XSLT stylesheet? I'm mostly curious if they were using XSLT 2.0. I'm doing a lot of XSLT stuff at work. I'd like to come up with some alternate ways of doing things to make some of the coding I'm doing lately fit together better.</description>
		<content:encoded><![CDATA[<p>Hi Ross - just started reading your blog recently. Can you tell me more about the problems you were having with the XSLT stylesheet? I&#8217;m mostly curious if they were using XSLT 2.0. I&#8217;m doing a lot of XSLT stuff at work. I&#8217;d like to come up with some alternate ways of doing things to make some of the coding I&#8217;m doing lately fit together better.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
