Home        Products        Solutions       Services

SITE MAP HOME PRODUCTS    XBRL Report Runner    XBRL API SOLUTIONS    XBRL My Way    Custom Solutions    OEM FAQ SERVICES    Taxonomy Creation    Taxonomy QA    Taxonomy Extension    U S GAAP (SEC) WHO WE ARE    Contact Us EXTERNAL LINKS    Save the Planet!    XML Schema    XBRL PRIVACY POLICY Below are some frequently asked questions, (and of course some answers!), that might help you enable your company and/or your customers: Rendering XBRL... How do I render an XBRL document in HTML? How do I display XBRL in Microsoft Excel or Microsoft Word? XBRL Taxonomies... I have to create a taxonomy extension - where do I start? I want to create a new taxonomy - is that hard? I've been looking at a taxonomy, but it is really hard to understand. What's with that? How does one assess the quality of a taxonomy? Are there any quality assurance tools available today? General XBRL... XBRL seems simple enough - why wouldn't I just process the XML files myself? Why would I use the Coyote Reporting XBRL processor? Why, for example, wouldn't I use an open source XBRL Processor? Rendering XBRL How do I render an XBRL document in HTML? The easiest thing to do is to use an XBRL-aware XSL processor. Many programmers are familiar with creating a stylesheet to render XHTML. The Coyote Reporting offers XBRL Report Runner as a straight-forward way to make this happen. The two key features that you need in any processor are: XSL (or XQuery) extension functions An easy way to run the XBRL-aware stylesheet How would I display XBRL in Microsoft Excel or Microsoft Word? Much like creating HTML, The easiest thing to do is to use an XBRL-aware XSL processor. The output should be one of the Microsoft Office XML standards, such as SpreadsheetML for Excel. Note that the Coyote Reporting processor not only provides XBRL-specific extension functions, it also provides Excel-specific extension functions for easily reading Excel. Yes, you read that right, reading Excel. A use case that we have seen frequently is that you want to process an Excel document, merge in XBRL information, and write out yet another Excel document. It turns out that reading SpreadsheetML directly can be more complex than it first appears. return to top XBRL Taxonomies I have to create a taxonomy extension - where do I start? Nominally, creating a taxonomy extension is exactly the same as creating an entire taxonomy, except on a much smaller scale. You must use either taxonomy creation software, or sophisticated "instance" software. While not technically required, when extending a taxonomy it is good practice to follow the architectural guidelines of the base taxonomy. We highly recommend that you use appropriate quality assurance standards so that you can assert that your extension is built correctly. I want to create a new taxonomy, is that hard? Creating a taxonomy is very similar to writing software. Lots of people in the world can write a few lines of HTML, Visual Basic, or Java. However, creating a good taxonomy requires sophisticated methodologies and tools—just like writing high-quality software solutions. And—just like creating software—creating a great taxonomy requires serious dedication. I've been looking at a taxonomy, but it is really hard to understand. What's with that? Taxonomies are indeed rather complex. First of all, look at a taxonomy through some sort of viewer: looking at the XML is just looking at "a bunch of angle brackets". An appropriate viewer will provide some sort of semantic rendering. Looking at the XML would be like trying understand a spreadsheet by looking Microsoft's SpreadsheetML. Looking at a taxonomy in an appropriate viewer doesn't necessarily solve the problem either (although it is better). Chances are you need to look at the preparer's guide associated with that taxonomy. Using a metaphor similar to the one above, Looking at a tax form doesn't really help much if you don't have any idea what is supposed to go in each field on the form. How does one assess the quality of a taxonomy? There are two aspects to evaluating the quality of a taxonomy. The first is the to assert that the domain is correct. The second is to assert that the taxonomy is built in a consistent manner so as to be usable. Today, the only way to assert that the domain is correct is to have domain experts available. If you are building a taxonomy for taxes, for example, make sure you have someone available that understands the tax law. The consistency issue, however, can and should be addressed with tools designed to assist in the QA process. Again, like building software, having the right tools available makes all of the difference. Briefly, you should have the following: Written architectural guidelines and style guides Tools that analyze the taxonomy and generate exception reports. An automated repeatable regession test suite. Are there any quality assurance tools available today? Of course! Coyote Reporting offers XBRL Report Runner™ which was used in the U S GAAP taxonomy project expressly for QA reports. We can help you design clear informative reports to support your taxonomy project. return to top General XBRL XBRL seems simple enough - why wouldn't I just process the XML files myself? If you are a software developer, you are probably used to looking at XML files. Furthermore, XLink doesn't seem that hard to process. At some level, processing XBRL is not that difficult. Here are a few things to consider that make commercial XBRL processors valuable: Writing code to process XBRL files is one thing, writing code that is reasonably fast is quite another. The difference between writing your own XBRL processor and buying one from, say, Coyote Reporting, could mean the difference between taking 1 or 2 minutes to load a taxonomy (or even part of a taxonomy), and 10 secs to load a taxonomy. XBRL relationships are quite complex. Any given "arc" can manifest itself into multiple relationships. Correct semantic interpretation of the the cross-product of arcs and locators is more difficult than it first appears. Prohibition (of relationships) is extremely convoluted. Getting this correct (and fast), is very difficult. Most corporations spend millions of dollars before they get a reasonably efficient XBRL processor. When they are done, the developers then realize the right way to do it, but never have a second chance. Coyote Reporting's processor is probably the only third-generation processor available on the market today. Why would I use the Coyote Reporting XBRL processor? Why, for example, wouldn't I use an open source XBRL Processor? If you are experimenting with XBRL, an open source processor might be fine. However if you are building a commercial application: You might want the fastest processor out there, and one that is reasonably memory efficient. These considerations have an impact on your user's perception, and possibly on the amount of hardware they have to buy. You might want XSL/XQuery XBRL extension functions that are designed to be easy to use in real applications, and hence require less development effort. You might want XSL/XQuery Microsoft Excel extension functions to make processing Excel documents a breeze. You might want to make money. A lot of open source code is GNU Public License (GPL), which frequently means that you can't charge for the product you build on top of that open source library. return to top Copyright © Coyote Reporting, LLC, 2007.   All Rights Reserved.