> What I am saying in a confused way, I think, is that
>
> 1) Information should not be lost. If it is _known_ (e.g. from service
> provider) that a number is a
> <Value><NumberLiteral><IntNum><Value>
> (why is Value twice? by the way...)
> then we should keep all the baggage.
Again I must reiterate. The call/agreement for ADQL was a parse tree
for SQL strings. As user I should hope you would never see the XML
representation but would use the string representation.
In which case you would like to say
select * from stars where mag < 15.5
The current ADQL parse will simply parse this according to SQL gramme and give you the tokens. Perhaps when people asked for a parse tree they expected something else ? The notion was to give something pre parsed to the node so node developers did not have to develop SQL parsers. Not that users should construct such documents. Portals perhaps from screens and forms but not users.
>
> 2) If information is not given, then any assumptions have to be applied
> with great care. e.g. 2 is assumed to be a number but it is safer to
> leave the type unspecified and make sure that if an application is
> expecting a real, it gets 2.0 (but not 2.0000000 or
> 1.99999985457965478007 etc....). Perl is the most intelligent language I
> have come across in this respect and might have some good things to copy
> if we need? But probably you guys know much more sophisticated ways.
When transmitting data I can see this being an issue. In a query I
do not see a problem with the SQL approach. The value on the right
15.5 above will have to be coercible to the type of the column on the
left. As you point out Perl is very good at this type of coercion - so
are most databases.
>
Received on 2004-01-29Z16:03:14