Michael Fox said:

> We are currently in the process of converting the stylesheet to the most
> recent syntax but want to wait until it is formally released.   We have
> reverse-engineered a version based on what Microsoft has released to
> date that does work in IE 5.0 but I doubt that it is a very elegant
> implementation.   Yes, EAD direct to your browser with no plug-ins.

Since last week, we have been experimenting with IE5's support for
XSL. After a rather frustrating process of trial-and-error and
second guessing with regard to the differences between the XSL
Working Draft and Microsoft's current implementation (which I accept
is inevitable at this stage of the standard's development), we have
managed to come up with a version (another less than elegant
production, I must confess!) of the XSL stylesheet which reproduces
in IE5 the rendition of the XML document which we were previously
achieving by performing the EAD>HTML transformation offline with XT.
And, yes, it is very exciting to see your EAD document prettily
rendered in a standard web browser and switch to "view source" and
see your original EAD-encoded finding aid sitting there.

I have one query which others exploring this field may be able to
help me with. As part of the transformation process, the stylesheet
outputs standard HTML "a href=...." hypertext links. Those which
point to external resources (i.e. other documents) function fine when
actuated from the IE5-rendered version. However, some of the links
are internal to the document - for example, a simple ToC is generated
for the main structural divisions, so we output something like:

<a href="#scopecontent">Scope and content</a>
.......
<a name="scopecontent"><h3>Scope and content</h3></a>
<p>.....

In the HTML document generated by the offline XSL processor, the
links function fine. But when I actuate such a link in the
IE5-rendered version, the browser returns a "page cannot be displayed
error". The address line of the browser display shows that it is
picking up the fragment identifier and resolving it relative to the
current document:

..../doc.xml#scopecontent

Of course I intend the target to be an anchor within the "HTML
document" which is output from the XSL transformation process,
whereas what seems to be happening is that IE5 interprets it as
within the XML source document (which is, after all, the "current
document"), and presumably because it doesn't (yet) have XPointer
functionality it can't handle that (and even if it did then the HTML
fragment identifier might not even exist as an id attribute in the
XML document).

Or am I missing something blindingly obvious here? Has anyone else
encountered/circumvented this problem? Or am I just asking too much
of IE5 at this stage in the game?!

Any thoughts much appreciated.

Pete