Upgrade stylesheet about edg_metadata HOT 4 CLOSED

DCAT xslt looks to be in metadata folder already - at least as a bare-bones starting point. Here is an example starting point:
https://edg.epa.gov/metadata/rest/document?id=%7B2677686C-D2A2-4EFE-A161-FD7FE849E750%7D&xsl=metadata_to_html_full
https://edg.epa.gov/data/PUBLIC/OEI/METADATA/EDI_metadata.json

from edg_metadata.

From: Suma Malothu [mailto:[email protected]]
Sent: Tuesday, June 28, 2016 10:31 AM
To: Hultgren, Torrin [email protected]
Subject: Re: [Innovate-Inc/EDG_metadata] Upgrade stylesheet (#3)

Hi Torrin,

One of the stylesheets are having issue with namespace(schemas-microsoft-com), bug was also created in ORACLE site.
(http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6409233)

Here is the error I was getting

SEVERE: InnoRestServlet processRequest threw exceptionjavax.xml.transform.TransformerConfigurationException: Error checking type of the expression 'FilterParentPath(funcall(urn:schemas-microsoft-com:xslt:nodeSet, []), step("child", -1))'.

File name ESRIISO2.xslt at line 25

(<xsl:variable name="eleID"><xsl:value-of select="generate-id(msxsl:node-set($elements1)/*[not(thesaName)][1]) or generate-id(msxsl:node-set($elements1b))" />/xsl:variable)

Please let me know how do we approach them.

From: Hultgren, Torrin
Sent: Tuesday, June 28, 2016 5:05 PM
To: 'Suma Malothu' [email protected]
Cc: Dan Spinosa ([email protected]) [email protected]; [email protected]; Pierson, Suzanne [email protected]
Subject: RE: [Innovate-Inc/EDG_metadata] Upgrade stylesheet (#3)

Hi Suma,

If I read the bug report right, it suggests that the stylesheet utilizes an XPath 2.0 expression, but the version of Java we’re working with only supports XSLT 1.0? I guess that means we have two options – work through the stylesheet and eliminate the XPath 2.0 expressions (try to convert them to equivalent 1.0 expressions) or evaluate options for upgrading the Java XSLT engine (I suspect that may not be feasible). I’m cc’ing Dan on this as he has a lot of experience with XSLT engines and might be able to offer suggestions.

Torrin
From: Hultgren, Torrin
Sent: Friday, July 01, 2016 5:55 PM
To: 'Suma Malothu' [email protected]
Cc: Dan Spinosa ([email protected]) [email protected]; '[email protected]' [email protected]; Pierson, Suzanne [email protected]
Subject: RE: [Innovate-Inc/EDG_metadata] Upgrade stylesheet (#3)

Ok, as we discussed on the phone it looks like I had this backwards. The XSLTs from ArcGIS Desktop are XSLT 1.0, and GeoPortal server is using an XSLT 2.0 parser. Buried deep in this page:
https://desktop.arcgis.com/en/arcmap/latest/manage-data/metadata/support-for-iso-metadata-standards.htm
ArcGIS for Desktop uses the Microsoft .NET Framework XML parser and XSLT processor to handle metadata. This technology exclusively supports XSLT 1.0. Therefore, only XSLT stylesheets based on XSLT 1.0 can be run using ArcGIS for Desktopsoftware. Schematrons created based on XSLT 2.0 cannot be transformed into an XSLT stylesheet that will run inArcGIS for Desktop.
So our question becomes – is there a way to ask GeoPortal Server to use an XSLT 1.0 parser for this display (set to backwards compatibility mode)? Or do we try working through upgrading these XLST 1.0 files to 2.0?
http://stackoverflow.com/questions/9387396/upgrading-xslt-1-0-to-xslt-2-0
Or do we start with the XSLT 2.0 files already in GeoPortal and try to manually emulate the look and feel of the ArcGIS Desktop style?

from edg_metadata.

So it actually turns out that GeoPortal Server is also using XSLT 1.0 exclusively, though Marten indicates he would like to eventually add an XSLT 2.0 parser. I think this StackExchange posting is a better fit for the problem - the difference is not 1.0 versus 2.0, it's Microsoft versus non-Microsoft:
http://stackoverflow.com/questions/9837589/result-tree-fragment-to-node-set-generic-approach-for-all-xsl-engines
The proposed solution seems straightforward, no?

from edg_metadata.

This issue was moved to USEPA/EPA_Environmental_Dataset_Gateway#21

from edg_metadata.