[OpenSpending] XBRL for Local Government Financial Reporting

Rufus Pollock rufus.pollock at okfn.org
Thu Sep 12 19:02:17 UTC 2013


This is great Friedrich - and follows on Marc's equally thoughtful piece.
Would you be up for having this cross-posted (either on blog.okfn.org or
OpenSpending)?  The points being raised here are important and more broadly
relevant ...

Rufus


On 12 September 2013 19:33, Friedrich Lindenberg <
friedrich.lindenberg at okfn.org> wrote:

> Thanks to Marc's kind introduction and encouragement, I've now written up
> a short piece on this in what I hope might be plain language:
>
>
> http://tabbforum.com/opinions/xbrl-standard-could-increase-technology-complexity-obscure-municipal-financial-disclosure
>
> Any feedback is very welcome,
>
> - Friedrich
>
>
> On Mon, Sep 9, 2013 at 4:34 PM, Martin Tisne <mtisne at omidyar.com> wrote:
>
>> + 1 on plain language blog! I have been sending this thread to various
>> colleagues but it's hard to decipher at times
>> ________________________________
>>
>> Martin Tisné
>> Director, Policy
>> Omidyar Network UK Limited
>> Cell: +44 782 388 7414
>> Landline: +44 20 7033 8655
>> Email: mtisne at omidyar.com
>> Twitter: @martintisne
>>
>> On 9 Sep 2013, at 14:21, Anders Pedersen wrote:
>>
>> > Hi all,
>> >
>> > Really great to see this discussion around XBRL vs. GTFS happen. I'd
>> love to see us to get up a blog post summarising the thoughts on th two
>> approaches. I think a plain language discussion of this would be really
>> appreciated in the wider spending community!
>> >
>> > Would anyone be up for recapping the past discussion here on the list
>> in a blog post?
>> >
>> > If you want to contribute a Trello ticket is ready to be claimed over
>> at our news board:
>> >
>> https://trello.com/c/x8fOQlxl/33-xbrl-or-gtfs-finding-the-right-path-for-a-spending-data-standard
>> >
>> > Anders
>> >
>> >
>> > On 5 September 2013 16:30, Marc Joffe <marc at publicsectorcredit.org>
>> wrote:
>> > Friedrich
>> >
>> >
>> >
>> > Thanks for exposing me to GTFS.  Yes, I could see the benefit of
>> migrating this type of approach from public transit to government financial
>> reporting. Certainly it is easier to read, write and compress a set of CSV
>> files than generate and process XBRL.
>> >
>> >
>> >
>> > I see that open source code is available for a feed validator at
>> https://code.google.com/p/googletransitdatafeed/.
>> >
>> >
>> >
>> > While this is all good, I am left with the following questions:  why
>> isn’t there already a GTFS equivalent for local government finance and how
>> could we get one built?  In the case of GTFS, it appears that Google had
>> both the incentive (more people using their maps) and the resources to
>> create the initial code and documentation.
>> >
>> >
>> >
>> > I don’t think there are enough eyeballs interested in Open Spending
>> data to motivate Google or a similar firm to make a similar investment.  If
>> not, is a non-profit like OKFn sufficiently resourced and organized to
>> fulfill the role that would otherwise be fulfilled by a not-for-profit?
>> >
>> >
>> >
>> > It seems that the weakness of XBRL in this case may also be a source of
>> strength. Because companies can make money from the complexity of XBRL they
>> have an incentive to promote it to legislators and regulators.
>> >
>> >
>> >
>> > Marc
>> >
>> >
>> >
>> > From: openspending-bounces at lists.okfn.org [mailto:
>> openspending-bounces at lists.okfn.org] On Behalf Of Friedrich Lindenberg
>> > Sent: Thursday, September 05, 2013 12:32 PM
>> >
>> >
>> > To: OpenSpending Discussion List
>> > Subject: Re: [OpenSpending] XBRL for Local Government Financial
>> Reporting
>> >
>> >
>> >
>> > 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] 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 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
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > openspending mailing list
>> > openspending at lists.okfn.org
>> > http://lists.okfn.org/mailman/listinfo/openspending
>> > Unsubscribe: http://lists.okfn.org/mailman/options/openspending
>> >
>> >
>> >
>> >
>> > --
>> > Anders Pedersen
>> > Community Coordinator  |  skype: anpehej  |  @anpe
>> > The Open Knowledge Foundation
>> > Empowering through Open Knowledge
>> > http://okfn.org/  |  @okfn  |  OKF on Facebook  |  Blog  |  Newsletter
>> >
>> > OpenSpending | http://openspending.org | @openspending
>> > School of Data | http://schoolofdata.org | @schoolofdata
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > openspending mailing list
>> > openspending at lists.okfn.org
>> > http://lists.okfn.org/mailman/listinfo/openspending
>> > Unsubscribe: http://lists.okfn.org/mailman/options/openspending
>>
>>
>> _______________________________________________
>> openspending mailing list
>> openspending at lists.okfn.org
>> http://lists.okfn.org/mailman/listinfo/openspending
>> Unsubscribe: http://lists.okfn.org/mailman/options/openspending
>>
>
>
> _______________________________________________
> openspending mailing list
> openspending at lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/openspending
> Unsubscribe: http://lists.okfn.org/mailman/options/openspending
>
>


-- 
*

Rufus Pollock

Founder and Executive Director | skype: rufuspollock |
@rufuspollock<https://twitter.com/rufuspollock>

The Open Knowledge Foundation <http://okfn.org/>

Empowering through Open Knowledge
http://okfn.org/ | @okfn <http://twitter.com/OKFN> | OKF on
Facebook<https://www.facebook.com/OKFNetwork>|
Blog <http://blog.okfn.org/>  |  Newsletter<http://okfn.org/about/newsletter>

*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/openspending/attachments/20130912/5d81853a/attachment.html>


More information about the openspending mailing list