Re: [xmlblaster] Errors when testing C-API

[Jan Petranek <jan at petranek.de>]

Am Donnerstag, 14. April 2005 03:05 schrieb Vaughn Combs:
> I wonder if either of you have any comments on this
> one. I posted this one almost 2 weeks ago but havent
> heard any responses:

(I only subscribed yesterday :-)

[...]
I assume, you did subscribe to the message using XPATH, i.e. 
<key querytype="XPATH">
/xmlBlaster/key[metadata/BasicTemporal/beginning_date_time_group/hour_time>=21 ]
</key>

> I have expected results for the following predicate:
>
> /xmlBlaster/key[metadata/BasicTemporal/beginning_date_time_group/hour_time>
>=21 ]
>
> but for:
>
> /xmlBlaster/key[metadata/BasicTemporal/beginning_date_time_group/hour_time<
>22]
>
> I get the following exception upon submission of the
> subscription:
>
> org.infospherics.commonAPI.impl.exception.PlatformFailureException:
> XmlBlasterException errorCode=[resource.configuration]
> serverSideException=false
> location=[SaxHandlerBase.parse()] message=[#exported
> Error while SAX parsing :1:-1 :
> org.xml.sax.SAXParseException: The content beginning
> "<2" is not legal markup. Perhaps the "2" ( )
> character should be a letter.] [See URL
> http://www.xmlblaster.org/xmlBlaster/doc/requirements/admin.errorcodes.list
>ing.html#resource.configuration]
>
> Any ideas or suggestions?

As Michele, I find the < and > suspicious. Not only because they may be 
interpreted by the shell. The error you received looks more like 
- XmlBlaster tried to parse the key as an xml document
- SAX (the parser engine) choked on the "<" 
- It did not choke on the ">"

Why? Because SAX looks for the next <xml-tag> or </end-tag>, that would be 
some sequence beginning with "<". So, it interprets 
x <2 as a typo for 
x <2> 

This also explains, why the ">" does not hurt: SAX would only care about a 
">", if an opening "<" was there.

So, Michele's suggestion to enclose your message in "double-" or 
'single-brackets' should also help in this situation. 

And finally, if XmlBlaster makes use of the key's DTD, the XPATH-expression 
could be a CDATA-Element (an unparsed Element) - but I do not know, if this 
would stop SAX from running into trouble.

Good night, 

Jan Petranek