Bug #2147

EML Stylesheet problem with web address URL's

Added by Callie Bowdish about 17 years ago. Updated over 13 years ago.

In Progress
Target version:
Start date:
Due date:
% Done:


Estimated time:


Data Set Description on the web for ID's like knb-lter-gce.77.8 to not link
correctly to the Web Address such as listed under Metadata Provider(s). Is this
a known problem - that the Data Set Descriptions Web Addresses do not direct
right because the address reads an additional http into the URL? here is an
example record from the KNB site knb-lter-gce.77.8
<sid> Callie - the links are adding the http:// in front of the urls
<sid> which alreadt have http in them
<sid> same is not true for Online Distribution Info
<Callie> anyway with the online Data Set Descriptions the Web links do not work
for some of the records and this one in particular knb-lter-gce.77.8
<Callie> an example is where the Metadata Provider(s): Web Address reads as but when you click on the link it tries to
go to http://http//
<sid> yep
<sid> i will have to check the xml stylesheets
<sid> eml stylesheets
--- vero_lunch is now known as vero
<sid> Callie - the extra http is hard coded each time into web addresses - i
think the problem was that is we dont add http:// then it messes up the urls
which dont have http in from
<sid> e.g. a link like this
<sid> will show up as
<Callie> yes, I've also seen problems with linking when just www is at the start
of an address rathern than http://www
<Callie> The only thing I was thinking was insisting that when people enter in
an address that it includes the http:// or other type of http2//: ect Maybe then
we wouldn't need the http:// to be added??
--- jinglunch is now known as jing
<sid> yes
<sid> example of that would be https:// or ftp://
<sid> maybe you can add a bug regarding this in the eml bugzilla...
<sid> if you do, specify that the bug is in eml stylesheets rather than in eml

eml-party.xsl (9.78 KB) eml-party.xsl Will Tyburczy, 03/15/2007 09:59 AM


#1 Updated by Will Tyburczy over 16 years ago

The problem seems to be limited to the online url section in eml-party.xsl,
which currently places a hard-coded "http://" in front of the value supplied in
the metadata when making the <a> tag. Maybe we could check to see if there's a
':' in the value supplied to see if a protocol? Wouldn't work in all cases, but
probably more than the current method.

#2 Updated by Will Tyburczy over 15 years ago

The stylesheet now checks for the string ':/' in the URL to determine whether or not the protocol is specified. If the string is matched, "http://" isn't placed in front to the URL for the link href.

#3 Updated by Callie Bowdish over 14 years ago

This bug was fixed with the last release of Metacat.

#4 Updated by Callie Bowdish over 14 years ago

It looks like the distribution URL could use the same fix as the other place that the web address is entered in. When a URL starts with www instead of http:// the link is changed to on the webpage

<distribution scope="document">
<url function="download">;/url>

The html file that gets generated is correct but the browser adds the domain address to href="www ... " type of references. If they have "http://" such as href="http://www..."
then the domain address is not added by the browser

If someone does not put the http:// as part of their address in the distribution URL we need to add it. Something like this documented fix will do that.

Here is the dp that has the problem and the section that doesn't work

<td width="15%" class="highlight">Download File: </td><td width="85%" class="secondCol"><a href="" target="_blank">;/a&gt;&lt;/td>

#5 Updated by Margaret O'Brien almost 14 years ago

these bugs are for stylesheet and documentation updates. changed to EML.2.1.0 priority 3, to be taken care of after changes to schema

#6 Updated by Margaret O'Brien almost 14 years ago

moving stylesheet bugs to P4 (after schema and documentation done)

#7 Updated by Margaret O'Brien over 13 years ago

Open stylesheet bugs are now associated with EML's Utility component

#8 Updated by Redmine Admin over 9 years ago

Original Bugzilla ID was 2147

Also available in: Atom PDF