There are a couple of different approaches to rendering XML into HTML on a
webserver. You can do server-side processing of the XML document. This
means that the webserver does the processing of the XML document and
transforms it into HTML for the client. A view source would only show the
client the HTML markup, not the XML document.
If you are doing client-side processing, then you are generally using some
type of script/cgi to determine whether the client browser supports
XML/XSL and if it does, the transformation takes place on the client
machine. This usually means that the client can view the XML source.
The best approach, IMO, is the first one, where the server always sends
back the same HTML code to every browser. This is better for
One of the disadvantages to allowing a client machine to view the XML
source is that you may have XML element's attributes that you have set as
audience="internal" that you don't want to public to see. However, this
problem can be eliminated by running your finding aids through a script
that strips out any such elements before placing them on the web.
On Fri, 11 Feb 2005, MicheleR wrote:
> Hi all --
> I've been exploring the various ways of rendering XML into HTML for viewing
> EAD finding aids. The simplest is obviously via an XSLT stylesheet that
> transforms it into HTML, letting the client's browser do all the work. I've
> looked at eadcbs1.xsl thru eadcbs4.xsl and they work in IE and Firefox, and
> I suspect they will work in Safari and Netscape as well. With some minor
> tweaks they will likely do what we need them to do in terms of displaying
> our FAs. But I'm wondering (since this seems so
> smack-my-forehead-and-say-"Duh!" easy) what if any are the drawbacks of this
> approach? If the user does a "view source" the entire XML document is right
> there for them to see -- one article that I read seemed to think that was a
> problem, but I'm not sure why that would be.
> The only major issue I can think of is that it relies on the user having a
> version of the browser that supports XSLT natively, and certainly that is a
> concern. Other than that, does anyone have some thoughts on this?