When I try to use a floating point value inside an XQuery expression the execution always fails. If I substiture the floating point literal with an integer literal the problem goes away. I am merely trying to mutiply the value of an attibute (it could just as well be an element) by a floating point value. Anyways some clarification regarding the handling of numbers and numeric variables would be appreciated. The bad code follows. For example:
FOR $c IN document(“c:\projects\xm_5_1\win32_tests\rgb_colors.xml”)//colormap/color # for each color get its RGB values and string name LET $r := string($c/@red) LET $g := string($c/@green) LET $b := string($c/@blue) # calculate the HSI value for this RGB based color LET $h := .77 * $r # or whatever RETURN # write out the computed HSI values for each RGB color
Yes you are right, we currently just support Integer values as numerical type in Quip (as has been observed in some other thread in this forum). Sorry, we should have mentioned this in the ReadMe file. I hope you did not waste to much time investigating this.
Perhaps you have some documentation for the capabilities of the prototype and the command line tool set? I would like to know how to use the prototype without having to systematically test its functionality. So if there is anything along those lines please let me know how to get a copy.
I probably once again have to disappoint you. Quip came into existence as a proto-type for playing around with the concepts of Quilt and experimenting with different language proposals. Eventually we tried hard to be as close as possible to the working drafts of the XQuery group.
However this means (implementing a proto type) that we were not very systematic in the way the different features were implemented. The major guideline were the W3C usecases, which you find in the quip package.
But as I see, people start to do more with quip than just learning something about XQuery (as I do, when I use Quip for several tasks). This means we now should be more acurate in describing its limitations (e.g. list the implemented build-in functions und supported data-types) and of course its features.
For the time being just some rule of thumb: * no namespace support * no build-in functions other than those used in the usecases * no types besides String and Integer and Lists * no type checking and schema support (there is still no type declaration syntax in the working draft, but there will be very soon as I hear from working group members.) * no dereference and reference operations * no node identity (==) just equality on string value of elements (as in original XPath recommendation) * just abbreviated XPath syntax
in the next release of Quip you will find: * full namespace support * better documentation of its limitations and strengths (promised!)