NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
Hi Nathan,
Actually, both types ("dataType" and "dataFormat") can contain any
string ("xsd:token"). The enumerated lists are just the current well
known values.
The XML Schema is a bit odd and not particularly obvious. Both types are
unions of "xsd:token" and a type that is a restriction of "xsd:token".
Best practice would be to omit if unknown. If known, decide on a string
to represent it and be consistent with that string. We are open to
adding values to the list.
Ethan
On 2/12/2010 10:09 AM, Nathan Potter wrote:
>
>
> Thanks Ethan! That's Exactly what I needed!
>
>
>
> The validation output from my catalog contains 2 warnings (repeated
> numerous times):
>
> ** warning: non-standard data type = unknown
> ** warning: non-standard dataFormat type = unknown
> **Warning: Dataset (data/nc/123.nc): is selectable but no data type
> declared in it or in a parent element
> **Warning: Dataset (data/nc/200803061600_HFRadar_USEGC_6km_rtv_SIO.nc):
> is selectable but no data type declared in it or in a parent element
>
> The dataType and dataFormat types both use restricted vocabularies, but
> neither offer an option for "unknown". In our service the source
> dataFormat may not be known (it is simply a DAP type).
>
> Is it better to omit these two metadata tags if their values are either
> not known or not on the list of accepted values?
>
> What's the best practice here?
>
>
> N
>
>
>
> On Feb 11, 2010, at 9:47 PM, Ethan Davis wrote:
>
>> Hi Nathan,
>>
>> Here's the reference doc for TDS 4.x:
>>
>>> http://www.unidata.ucar.edu/Projects/THREDDS/tech/tds4.0/reference/CatalogService.html
>>>
>>
>> And here's a validation URL that works for your catalog:
>>
>>> http://motherlode.ucar.edu:8080/thredds/catalogServices?command=validate&verbose=true&catalog=http://206.125.94.252:8080/opendap/data/nc/catalog.xml
>>>
>>
>> Ethan
>>
>>
>> On 2/9/2010 3:12 PM, Nathan Potter wrote:
>>>
>>>
>>> Ethan,
>>>
>>> I want to validate the THREDDS catalog output of my server.
>>>
>>> I looked here:
>>>
>>> http://www.unidata.ucar.edu/Projects/THREDDS/tech/reference/CatalogService.html
>>>
>>>
>>>
>>> And I tried this:
>>>
>>> http://motherlode.ucar.edu:8080/thredds/catalogServices?cmd=validate&debug=true&catalog=http://206.125.94.252:8080/opendap/data/nc/catalog.xml
>>>
>>>
>>>
>>> Which returned an HTML presentation of the catalog but no debugging
>>> information. At this point I am guessing that any debugging output for
>>> my catalog is living in the TDS output logs on motherlode.ucar.edu
>>>
>>> Is there another validation service that returns more information that I
>>> might use? Or is the solution for me to run my own TDS and use it to
>>> validate catalogs from my THREDDS service?
>>
>
> = = =
> Nathan Potter ndp at opendap.org
> OPeNDAP, Inc. +1.541.231.3317
>
>
>
thredds archives: