Changes
→linking url:
However, don't despair, there are a few things you can count on. The <display_text> element will always include the label or heading that is to be used for the response. A <notes> element may be present with additional explanatory text. These alone, plus a linking url, will be enough for many clients.
===== linking url: <umlaut_passthrough_url> =====
You may see the <url> element in the response and be tempted to use it to send the user to this response. '''You are strongly cautioned not to do so.''' In the Umlaut architecture, urls can be generated on-demand when the user clicks on an element, not at time of original response (this is because even generating the url is sometimes an expensive operation). This means that the <url> element is not guaranteed to be there, and when it is there is not guaranteed to be accurate. On top of all that, the application of a proxy pass through won't be applied yet to the url found here.
You should instead use the <umlaut_passthrough_url> element. This will contain a URL pointing to your umlaut installation, of the form: http://umlaut.university.edu/link_router/index/7447333
When this URL is accessed, Umlaut will '''redirect''' the user to the actual destination--after calculating that destination, and applying any proxy or other filters, etc. In some cases it may end up redirecting to the same destination as <url>, but in other cases it may be somewhat different, or may work even if <url> was not present.
===== other conventions =====
Each ServiceTypeValue has other conventions for elements that will be present in that ServiceTypeValue. These are documented in [http://umlaut.rubyforge.org/api/classes/ServiceResponse.html ServiceResponse] in the Conventional Keys section.