[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Early Draft Review: XQuery for Java (JSR 225)

• To: "Burak Emir" <Burak.Emir@e...>
• Subject: Re: Early Draft Review: XQuery for Java (JSR 225)
• From: "Ken North" <kennorth@s...>
• Date: Wed, 16 Jun 2004 16:50:02 -0700
• Cc: <xml-dev@l...>,<jsr-225-comments@j...>
• References: <20040527220043.IFPQ20971.mta09-svc.ntlworld.com@Turtle> <40B6F9F1.1080104@e...> <6.0.0.22.2.20040608162857.05bbf708@g...> <40CDDACF.1070201@e...> <003201c45256$02145ad0$1601a8c0@DURANTE> <40CED01E.9050805@e...>

> What you say is quite impossible - maybe I am not clear enough:
> the simple static analysis I am aiming at is made by the *Java
> compiler*: correct syntax of the query, and possibly some type-checking.
> This catches the "easily avoidable errors".

My point is you can use the prepare step to validate the query. It's not compile
time, but it's pre-execution.

> Let us suppose you want to use such a tool: every abstract syntax tree
> can be serialized to concrete syntax with no effort.

Suppose I want to [build | buy ] a query logger, performance monitor, trace tool
or query designer that's programmed in C++ or Visual Basic. It can process or
generate XQuery strings, but it's unlikely to "understand" encrypted Java
bytestreams.

• Follow-Ups:
  • Re: Early Draft Review: XQuery for Java (JSR 225)
    • From: Burak Emir <Burak.Emir@e...>

• References:
  • Re: Early Draft Review: XQuery for Java (JSR 225)
    • From: Burak Emir <Burak.Emir@e...>
  • Re: Early Draft Review: XQuery for Java (JSR 225)
    • From: "Ken North" <kennorth@s...>
  • Re: Early Draft Review: XQuery for Java (JSR 225)
    • From: Burak Emir <Burak.Emir@e...>

• Prev by Date: Re: New Infoworld article on XML and relational databases
• Next by Date: Microsoft Proves Pronouns Patentable
• Previous by thread: Re: Early Draft Review: XQuery for Java (JSR 225)
• Next by thread: Re: Early Draft Review: XQuery for Java (JSR 225)
• Index(es):
  • Date
  • Thread