Re: [thredds] TDS Catalog Validation Service

Hi Nathan,

1) The xlink:href attribute value can be a relative or absolute URL. It
is relative to the containing catalogs base URL. Yup, all your examples
look good.

2) Your construction of the dataset access URL looks good. The details
are described in the THREDDS Catalog specification

http://www.unidata.ucar.edu/projects/THREDDS/tech/catalog/v1.0.2/InvCatalogSpec.html#constructingURLs

Key points:
a) the service base is a relative or absolute URL with relative URLs
resolved against the catalog base URL;
b) the other values are strings that are appended to the resulting
service base URL.

Ethan

Nathan Potter wrote:
> John,
> 
> Point me at the crawler code, I'll look and see how it works with  
> thredds:catalogRef elements.
> 
> I guess I really have two questions:
> 
> 
> 1 ------------------
> 
> I am looking at the xlink:href attribute of the thredds:catalogRef  
> elements.
> 
> 
> Would it be far to say that this example:
> 
>      <catalogRef xlink:href="CEOP/catalog.xml" xlink:title="CEOP"  
> name="CEOP/"/>
> 
> References a file relative to the parent catalogs position in the  
> catalog structure?
> 
> 
> Example 1:
> So if the catalog containing this thredds:catalogRef was accessed  
> using this URL:
> 
>      http://localhost:8080/thredds/data/catalog.xml
> 
> Then the above catalogRef should lead you here:
> 
>      http://localhost:8080/thredds/data/CEOP/catalog.xml
> 
> 
> Example 2:
> And on the same server, this example:
> 
>      <catalogRef xlink:href="/toplevel/path/catalog.xml"  
> xlink:title="catalog" name="catalog"/>
> 
> Would lead here:
> 
>      http://localhost:8080/toplevel/path/catalog.xml
> 
> No matter which catalog this thredds:cataogRef appeared.
> 
> 
> Example 3:
> And this example:
> 
>      <catalogRef 
> xlink:href="http://motherlode.ucar.edu:8080/thredds/idd/satellite.xml 
> " xlink:title="Motherlode" name="Motherlode"/>
> 
> Would lead here:
> 
>      http://motherlode.ucar.edu:8080/thredds/idd/satellite.xml
> 
> No matter which catalog this thredds:cataogRef appeared.
> 
> Is that the way you see it working?
> 
> 
> 
> 
> 
> 2 ------------------
> 
> Is there a place that describes how data access URL's are too be built  
> from thredds:dataset elements ?
> 
> My understanding is that it's like this:
> 
>    thredds:service/@base + thredds:dataset/@urlPath
> 
> Is that a correct interpretation of the catalog semantics? So if we're  
> on localhost:8080,  and the service/@base is "/opendap/" then this  
> catalog snippet:
> 
>   <service name="hyrax" serviceType="OPeNDAP" base="/opendap/"/>
>   <dataset name="Datset with a compound service and multiply inherited  
> services." ID="bears" urlPath="bears.nc">
>     <serviceName>hyrax</serviceName>
>   </dataset>
> 
> Would produce this base data access URL:   
> http://localhost:8080/opendap/bears.nc 
>   and additional service related stuff would get added to that.
> 
> Is that right?
> 
> 
> Thanks,
> 
> Nathan
> 
> 
> 
> 
> On Dec 30, 2008, at 9:16 AM, John Caron wrote:
> 
>> Hi Nathan:
>>
>> We dont have ready-made code that validates catalogs and follows the  
>> catalog refs. However, we do have some generic catalog crawler code,  
>> where you get callbacks to your own code to do whatever you want.  
>> let me know if thats helpful...
>>
>> Nathan Potter wrote:
>>> Greetings,
>>> I have a question about validating the semantics of a THREDDS  
>>> catalog. The attached catalog contains a number of  
>>> thredds:catalogRef elements. The urlPath attribute for these should  
>>> be able to be used to resolve the individual catalogs. Is there a  
>>> validation for that similar to  using the built in Catalog  
>>> Validation service that come rolled in the TDS?
>>> I tested the attached catalog against the service at  
>>> motherload.ucar.edu:
>>> http://motherlode.ucar.edu:8080/thredds/catalogServices?cmd=validate&catalog=http://ndp.opendap.org:8080/opendap/data/catalog.xml
>>>  
>>>  And it passed, but I don't imagine it attempted to check down the  
>>> catalog hierarchy.
>>> Any ideas?
>>> Thanks,
>>> Nathan
>>> ------------------------------------------------------------------------
>>> = = =
>>> Nathan Potter                        ndp at opendap.org
>>> OPeNDAP, Inc.                        541.752.1852
>>> ------------------------------------------------------------------------
>>> _______________________________________________
>>> thredds mailing list
>>> thredds@xxxxxxxxxxxxxxxx
>>> For list information or to unsubscribe,  visit: 
>>> http://www.unidata.ucar.edu/mailing_lists/
> 
> = = =
> Nathan Potter                        ndp at opendap.org
> OPeNDAP, Inc.                        541.752.1852
> 
> 
> _______________________________________________
> thredds mailing list
> thredds@xxxxxxxxxxxxxxxx
> For list information or to unsubscribe,  visit: 
> http://www.unidata.ucar.edu/mailing_lists/ 

-- 
Ethan R. Davis                                Telephone: (303) 497-8155
Software Engineer                             Fax:       (303) 497-8690
UCAR Unidata Program Center                   E-mail:    edavis@xxxxxxxx
P.O. Box 3000
Boulder, CO  80307-3000                       http://www.unidata.ucar.edu/
---------------------------------------------------------------------------


  • 2008 messages navigation, sorted by:
    1. Thread
    2. Subject
    3. Author
    4. Date
    5. ↑ Table Of Contents
  • Search the thredds archives: