Re: Error occurring in dods.dap.Parser


On Jan 27, 2005, at 8:52 AM, James Gallagher wrote:


On Jan 26, 2005, at 9:30 PM, Tennessee Leeuwenburg wrote:

Unfortunately that seems to break thredds's parsing of catalogConfig.xml.

Hmmm. If you look in Java-DODS/dods/dap/parser/DDSJava.jj you can see the characters that the scanner gobbles up. I'm not really sure how the THREDDS code works.

If you have the parser generator, you could try adding '=' and ',' to the set of allowed chars. You'd need to be careful though because = and ',' are used by the CE syntax. So you can have them be part of a dataset name, but if they are a variable name the CE parser will become very confused.

A more sweeping solution (besides switching to XML, which is in the works) would be to modify the parser so that it uses a double quote (") to quote chars so any char could be part of a word (you'd do the usual thing about providing for quotes in the set of chars itself). This would be a more drastic change to the parser but would also dovetail with the current parser (I think) and not require a switch to XML (which solves the problem because it provides for robust quoting).


I am concerned that if Tennessee's modifies his code (especially our parser) to handle these names then he will be generating DDS's that no one else can parse...




James


If I convert
<dataset name="Single-level Salinity Data" urlPath="stream=ocea,param=200,DATE=20000101,TIME=0000,STEP=0,EXPVER=0 oc7,CLASS=RD,TYPE=AN,NUMBER=0,METHOD=0,LEVELIST=7.000,LEVTYPE=DP,REPRE S=LL,DOMAIN=G,salinity.nc"/>

to

<dataset name="Single-level Salinity Data" urlPath="stream%3Docea,param=200,DATE=20000101,TIME=0000,STEP=0,EXPVER =0oc7,CLASS=RD,TYPE=AN,NUMBER=0,METHOD=0,LEVELIST=7.000,LEVTYPE=DP,REP RES=LL,DOMAIN=G,salinity.nc"/>

that is to change the first "=" to %3D, the hex code for "=", it seems to break the lookup. What I get is the error

Error {
   code = 1;
message = "Dataset not found in catalog; urlPath= <stream=ocea,param=200,DATE=20000101,TIME=0000,STEP=0,EXPVER=0oc7,CLAS S=RD,TYPE=AN,NUMBER=0,METHOD=0,LEVELIST=7.000,LEVTYPE=DP,REPRES=LL,DOM AIN=G,salinity.nc>";
};


It would seem that thredds is converting the %3D to "=" in its head, then failing on the string comparison. Just my guess though.

Cheers,
-T




T,

Well. The problem is in your Dataset name:

} stream=ocea,param=200,DATE=20000101,TIME=0000,STEP=0,EXPVER=0oc7,CL ASS =RD,TYPE=AN,NUMBER=0,METHOD=0,LEVELIST=7.000,LEVTYPE=DP,REPRES=LL,D OMA IN=G,salinity.nc;


The parser is barfing on the first "=" character (Line 58, column 9)

James? Is this in any way a legal name? If so, how does he need to "escape" the "=" (and possibly the ",") characters?


You could escape the '=' and ',' using the HTTP %<hex digit><hex digit> notation, I think. When the Java DAP 2.0 parser was written we had not encountered file names that broke the 'C identifier' mold. But that was just around the corner... Anyway, the C++ code lets just about anything be a file name. I'd try the escaping scheme and see how it works.

James

PS. I just checked the DDS parser and it will grok the percent sign, so you should be OK using that to signal the start of the escape sequence.



--
James Gallagher                jgallagher at opendap.org
OPeNDAP, Inc                   406.783.8663


=======================================================
Nathan Potter              Oregon State University, COAS
ndp@xxxxxxxxxxxxxxxxxxxx   104 Ocean. Admin. Bldg.
541 737 2293 voice         Corvallis, OR   97331-5503
541 737 2064 fax


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