[OpenSpending] XBRL for Local Government Financial Reporting

Thu Sep 5 19:31:37 UTC 2013

Marc,

thanks for your response. I understand that XBRL already has a "regulatory
footprint", and that this may make it simpler to pitch it. The problem with
this approach is that its using politics to define technical interfaces, a
process which has brought us lots of the funnies failures of eGovernment.
Different problems require different solutions, and business accounting and
government finance are fairly different domains.

Additionally, complex XML formats like this tend to create the following
process:

Government ERP -> lossy conversion to idiomatic XBRL -> more lossy
conversion to a format that people could use. -> presentation.

This kind of conversion has caused real trouble for the adoption of IATI
(basically every consumer now builds their own REST API to cover the mess
of different IATI dialects). The promise of being able to use common
interfaces for this data just never became true, because the complexity of
XML (and XBRL) actually makes it less likely that different systems will be
speaking the same language. I'm dealing with another example of
heterogeneous XML right now, and it's hell to code:
https://github.com/pudo/ted-xml/blob/master/forms/contract_award.py.

As an alternative, take Google's GTFS. The format is a zip bundle of CSV
files and it's easy enough that virtually any larger municipality on this
planet can produce it; I've also seen parsers for it written in hours. Of
course you can have validation for it, just like XML schema: taxonomies are
tables, too.

Why not think along the lines of GTFS?

- Friedrich

On Thu, Sep 5, 2013 at 2:48 PM, Marc Joffe <marc at publicsectorcredit.org>wrote:

> Paul****
>
> ** **
>
> XBRL is just a dialect of XML. As such it allows a provider of data to
> validate his or her input prior to sending it to third parties.****
>
> ** **
>
> For example, the data I extracted from California Credit Scoring and
> submitted to Open Muni Budget during the Hasadna Hackathon was messy.
> Specifically, we had a lot of spelling variations across different cities
> for revenue and expenditure items.   This kind of issue could be detected
> prior to import by validating the XML against a taxonomy using
> off-the-shelf tools like Altova XMLSpy.  ****
>
> ** **
>
> The strength of XBRL as opposed to CSV and JSON is that it encourages the
> development of a standard for presenting revenue, expenditure and other
> fiscal information in a reliable way that can work with a variety of
> software solutions (Open Spending, Open Muni Budget, etc.).****
>
> ** **
>
> Regards,****
>
> Marc****
>
> ** **
>
> *From:* openspending-bounces at lists.okfn.org [mailto:
> openspending-bounces at lists.okfn.org] *On Behalf Of *Paul Walsh
> *Sent:* Thursday, September 05, 2013 9:32 AM
> *To:* OpenSpending Discussion List
> *Subject:* Re: [OpenSpending] XBRL for Local Government Financial
> Reporting****
>
> ** **
>
> What is the problem that XBRL solves, and how does it do so in way that
> can't be done with CSV or JSON or other data formats that are easily
> accessible?
>
> On Thursday, September 5, 2013, Friedrich Lindenberg wrote:****
>
> Hey Marc, ****
>
> ** **
>
> this is very interesting to see XBRL being picked up, but I have to say
> that I'm critical of its use for non balance-sheet data [1]. XBRL is
> basically a massive framework in which any type of data could be expressed
> (it seems very committee-run), but the benefits really aren't clear to me.
> ****
>
> ** **
>
> You can have well-documented CSV or JSON, too - and for those formats
> there is tooling which is useable by journalists and other end-users who do
> not have the means to start a 3 year XBRL implementation effort. In the
> end, releasing government data as XBRL could mean that only solutions from
> large companies like IBM or SAP would be able to invest the effort
> necessary to interpret the data.****
>
> ** **
>
> Of course it would be nice to have a standard, but this one is so large
> and ambiguous, I can't see it being useful in a technical sense. ****
>
> ** **
>
> Cheers, ****
>
> ** **
>
> - Friedrich ****
>
> ** **
>
> ** **
>
> [1] http://openspending.org/resources/gift/chapter4-2.html ****
>
> ** **
>
> On Wed, Sep 4, 2013 at 8:38 PM, Marc Joffe <marc at publicsectorcredit.org>
> wrote:****
>
> Concha****
>
>  ****
>
> Thanks for these questions. ****
>
>  ****
>
> Like PDFs, XBRL files can either be published or kept confidential.  The
> use of XBRL by itself is not a guarantee of transparency.  However, a
> publicly available machine readable file is better than a publicly
> available PDF, since it is easier to process.  In the world of machine
> readable files, I see XBRL as better than CSV because XBRL tags allow for
> more complete self-documentation of the data, especially if it the data is
> complex.****
>
>  ****
>
> I don’t know how many Spanish cities actually file in XBRL format.  I
> thought the fact that they had a fairly well developed site (at
> http://www.e-local.es/index.html ) indicated a substantial investment and
> perhaps substantial compliance.  On the other hand, I am not seeing recent
> updates.****
>
>  ****
>
> I see some Spanish local government statistics here:
> http://www.minhap.gob.es/EN-GB/ESTADISTICA%20E%20INFORMES/Paginas/estadisticaseinformes.aspx.
> Have you see this before?****
>
>  ****
>
> Regards,****
>
> Marc****
>
>  ****
>
> *From:* openspending-bounces at lists.okfn.org [
> mailto:openspending-bounces at lists.okfn.org<openspending-bounces at lists.okfn.org>]
> *On Behalf Of *Conchita Catalan
> *Sent:* Wednesday, September 04, 2013 3:38 PM
> *To:* openspending at lists.okfn.org****
>
>
> *Subject:* [OpenSpending] XBRL for Local Government Financial Reporting***
> *
>
>  ****
>
> Hello Marc, ****
>
> Thank you for sending the article. It says ****
>
>  ****
>
> "In Spain, the *local government ministry encourages*<http://www.e-local.es/index.html> more
> than ****
>
> Unsubscribe: http://lists.okfn.org/mailman/options/openspending****
>
> ** **
>
>
>
> -- ****
>
> *Paul Walsh*****
>
> 0543551144****
>
> ** **
>
> _______________________________________________
> openspending mailing list
> openspending at lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/openspending
> Unsubscribe: http://lists.okfn.org/mailman/options/openspending
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/openspending/attachments/20130905/bb6e6426/attachment.html>