The following section deals with issues you may have while using YQL Open Data Tables:

  • Problem: The SELECT URL doesn't parse correctly in my Open Data Table definition.

    Solution: Make sure you've escaped things correctly for XML; for example: & should be encoded as &.

  • Problem: My Open Data Table definition has multiple bindings with different sets of keys. YQL keeps running the "wrong" select. How can I get YQL to choose the right one?

    Solution: Keep in mind that the order of bindings is important. Once YQL finds a select that satisfies the YQL statement, it uses that one. Try moving the more "specific" select endpoint above the others.

  • Problem: If my API requires authentication, how do I access it?

    Solution: If you want to use an API that requires its own authentication mechanism, you use the execute sub-element within an Open Data Table to manage this authentication.

  • Problem: Open Data Tables seem so complicated? What is the best way to get started?

    Solution: The best way to avoid being overwhelmed is to first look at examples. In general, when creating YQL tables, it is useful to take a bottom-up approach and analyze the result structure of the API(s) that you are encapsulating. First, group together all the services that produce the same result structure. This becomes your "table" or Open Table definition. For each API that produces the response structure, you should create a "select" under the "request" section of the Open Data Table definition. By using this mechanism, you can often consolidate multiple API's into a single versatile YQL table that allows YQL to do the heavy lifting and keep the implementation details hidden.

Table of Contents