[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Error occurring in dods.dap.Parser
- Subject: Re: Error occurring in dods.dap.Parser
- Date: Thu, 27 Jan 2005 10:09:50 -0700
On Jan 27, 2005, at 9:58 AM, Nathan Potter wrote:
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...
Duh. What was I thinking. Morning... Anyway, yeah, that's a problem. If
the system is for internal use only, it's not such a big deal and we
should probably modify the parsers as I described anyway.
James
James
If I convert
<dataset name="Single-level Salinity Data"
urlPath="stream=ocea,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"/>
to
<dataset name="Single-level Salinity Data"
urlPath="stream%3Docea,param=200,DATE=20000101,TIME=0000,STEP=0,EXPVE
R=0oc7,CLASS=RD,TYPE=AN,NUMBER=0,METHOD=0,LEVELIST=7.000,LEVTYPE=DP,R
EPRES=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,CLA
SS=RD,TYPE=AN,NUMBER=0,METHOD=0,LEVELIST=7.000,LEVTYPE=DP,REPRES=LL,D
OMAIN=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,C
LASS
=RD,TYPE=AN,NUMBER=0,METHOD=0,LEVELIST=7.000,LEVTYPE=DP,REPRES=LL,
DOMA 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
address@hidden 104 Ocean. Admin. Bldg.
541 737 2293 voice Corvallis, OR 97331-5503
541 737 2064 fax
--
James Gallagher jgallagher at opendap.org
OPeNDAP, Inc 406.783.8663