We chose to use a kind of hybrid approach -- we use the EAD for indexing for search purposes so we can take advantage of EAD tags like unitdate and genreform, but we produce static html to display to the end user. We initially chose this approach because we didn't want to rely on the end user's browser capabilities (waaaaay back then not all browsers were XML-capable, plus we had some large-ish files and thought they might be a bit much for slow connections/low-end machines to deal with). We've stuck to this method so far partly out of inertia but also because we use external entities for things like our institution name, and although IE will happily deal with those when rendering XML, Firefox -- surprisingly -- still doesn't.
An additional benefit of rendering HTML on the server side is that you can hide information in file (appraisal value, for example) that you don't want the general public to see. If you serve up the XML directly you can "hide" it via a style sheet, but if the user does "View source" they'll still see the entire file.
The only real benefit of giving the XML out directly is that you don't have to keep two sets of files around, but storage is pretty cheap and XML files are small, so...
From: Encoded Archival Description List [mailto:[log in to unmask]] On Behalf Of Daniel Pitti
Sent: Wednesday, March 31, 2010 7:54 AM
To: [log in to unmask]
Subject: Re: problem with a reference to an xsl stylesheet i do not have
Of course one way to get around all of these possible problems is to
do as Michael at first reasonably assumed was being done, convert the
ead-encoded finding aid to html in Oxygen and serve the resulting
html. There will be (or should not be) any URL or security issues
associated with that technique. And unless I am overlooking something,
there is no advantage to client-side rendering of the XML. In fact,
one gets around the inconsistencies in the different browsers'
handling of XSLT even if one then has to deal with inconsistencies in
how browsers render html and css.