UWS result URL - is relative URL okay?

[Rick Ebert]

Glad to read that "URL" still means .  I interpreted "URI" across the
IVOA documents to mean "per https://tools.ietf.org/html/rfc3986".

This is an area I have been hoping for some clarification - though not
related to this specific example:

There is a case to be made for some kind of help in interpreting XML
when it is 'saved' and later used by something that
is "not" a browser.    How does one resolve the Base context of a
relative URL/I ?

Section 5.1 of rfc3986 describes a few methods for estabishing a "Base
URI" via what i will describe as
 inheritance from the content and provenance of the URI. 

In cases where the provenance (Retrieval URI) must be known, then the
base can come from that.
  So for things like the present case,  how to get to the result when
the process is done - the Base can
  be inferred.  ok.

But what of the URLs (say to Links or other things) in the result XML? 
(VOTABLE).
As far as I can tell IVOA tables (XML) don't provide for <BASEURI
href=""\>  or other formulation.
So there's a bit of a gap there.
Apparently some tools have gone to the extent of rewriting relative URL
with the base of the retrieved file
INTO the returned XML before writing it ... Yikes...

IVOA should stay OUT of the business of picking apart adopted standards,
and accepting/requiring/supporting
only some part of them.  

URLs are not intended to be permanent,  and they move, often, so even an
absolute URL in a VOTable won't help
much.   A URI from which a URL can be derived is more helpful,   at
which point common prefixes can help reduce bloat of
these files immensely.  But, URI can only be helpful if there is some
way to resolve them into a URL:  which is what I Thought
the "Registry" was for many years ago.   URLs can/could be maintained
through redirects to a new URL,
but generally this fails because there's no funding, or people simply
move on to other things.



On 11/1/19 2:48 PM, Brian Major wrote:
> Hi Christine,
>
> I don't see text in the spec that would indicate that relative URLs
> are not allowed either, and they are legitimate values for 'anyURI'.
>
> https://www.w3.org/TR/xmlschema11-2/#anyURI
>
> But since they're not mentioned in UWS I'd say the regular rules
> determining the base of relative URLs should be applied
> (https://www.w3.org/TR/WD-html40-970917/htmlweb.html section 5.1.2),
> in which case they would be relative to the result-list endpoint.  One
> would get the result that contains the relative URL from:
>
> /{jobs}/{job-id}/results/{myresult}
>
> Which would contain (for example) ./rel-url/to/result
>
> And resolve to
>
> /{jobs}/{job-id}/results/rel-url/to/result
>
> This seems to agree with the sentence in section 2.2.2.3 of UWS "A
> sensible default for their URIs is to make them children of
> /{jobs}/{job-id}/results, but this is not required.".
>
> Cheers,
> Brian
>
>
> On Thu, Oct 31, 2019 at 1:09 PM Christine Banek <CBanek at lsst.org
> <mailto:CBanek at lsst.org>> wrote:
>
>     Hi all,
>
>
>     I just got an interesting bug report on pyvo today and after
>     reading the UWS spec hoping for some clarity, I'm at a loss if
>     this is allowed.  Here's the original issue:
>
>
>     https://github.com/astropy/pyvo/issues/191
>
>
>     Basically, the result URL field in a UWS async job is a relative
>     URL.  Is this allowed / part of the spec?  If relative is allowed,
>     is that URL considered relative to the UWS Job URL?  Since it
>     seems to work with TOPCAT, I've added Mark as well to get his
>     feelings.
>
>
>     Thanks all,
>
>     Christine
>
-- 
Rick Ebert
Caltech/IPAC
Engineer, NASA/IPAC Extragalactic Database

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/grid/attachments/20191104/2eb40ac6/attachment-0001.html>