Thank you Michele for taking a look. We do have some available workarounds, though I will certainly miss the ease of transformations with a browser that just, you know, worked!

Gina Strack

On Thu, Jul 18, 2019 at 7:57 AM Michele R Combs <[log in to unmask]> wrote:

I hadn’t run into this, but just tested it -- I have Firefox 68 and yep, I see this behavior as well.  Thanks for the discussion links, very interesting.  This is pretty annoying, and I’m guessing will create problems for a lot of people.  I’ve been using the local-folder-plus-browser method to teach EAD in my workshops for years, since the browser is by far the simplest method of allowing folks to preview their finding aids.  Guess I better start thinking about some other approach….

 

Here are three workarounds I can think of, off the top of my head:

 

1) Instead of previewing using a folder on your local machine, preview using a folder somewhere on your server.  That way it isn’t using file:///  See for example https://library.syr.edu/digital/guides/lavender/student_files/aaa_template.xml which is an EAD file referencing a style sheet in the same folder on our server (right click and View Source to see it).  You’d need to set up a folder on your server, preload it with whatever style sheets you need, and then use FileZilla or something to upload the file you want to preview.  If I remember correctly, Firefox has to be able to validate an XML file against the dtd in order to apply XSL and display it, so if your files are currently pointing to a local copy of ead.dtd you may need to upload that as well and/or tweak where the file is pointing.

 

2) Switch to another browser for your previewing.  Internet Explorer (ugh) and Safari should still work for this.  Edge might – I just tried it on my workstation and it displayed correctly, but last time I taught EAD some of my students reported problems with it if they were on a tablet.  Chrome I don’t think ever did.  I haven’t tested any of the others (e.g. Opera).

 

3) Do a quick transform to HTML and view it that way, instead of viewing the raw EAD.  This is how our EAD production works – we have a batch file set up that uses Saxon to generate HTML, so whenever we want to view the finding aid we just double click the batch file and poof, there it is.

 

Michele

 

From: Encoded Archival Standards List <[log in to unmask]> On Behalf Of Gina Strack
Sent: Wednesday, July 17, 2019 7:33 PM
To: [log in to unmask]
Subject: Firefox 68 and XML style sheets

 

I'm not sure if anyone else has already experienced this, but I've just started experiencing a new error with XML and XSLT in Firefox 68. Apparently when referencing a style sheet, even if in the same folder, the browser blocks it from transforming XML client-side.

 

CORS requests may only use the HTTPS URL scheme, but the URL specified by the request is of a different type. This often occurs if the URL specifies a local file, using a file:/// URL.

To fix this problem, simply make sure you use HTTPS URLs when issuing requests involving CORS, such as XMLHttpRequest, Fetch APIs, Web Fonts (@font-face), and WebGL textures, and XSL stylesheets.

According to this discussion, a workaround is to change browser settings to reverse the update, but I'm not one to mess around with those, and it'll be difficult to get that info out to all affected staff.

 

We normally preview finding aids by opening a browser with a LAN network file (so it starts with file:///) that references a style sheet stored in the same folder. To publish it online, we save a new version without a style sheet reference and batch transform to HTML on a monthly basis. We don't directly edit the XML but work in a system that outputs EAD 2002 files.

 

I'd love to hear if anyone has already solved this problem or has any suggestions to help us continue to preview finding aids.

 

Thank you,

Gina Strack

 

Digital Archives Manager | Certified Archivist

Utah State Archives & Records Service
https://archives.utah.gov
Phone (801) 531-3843
[log in to unmask]