XBRL Versioning: A user centered approach

1
XBRL VersioningA user centered approach

• César Pérez-Chirinos
• Secretary of Development Training Working Group
  (GTDF) of XBRL Spain

2
About the Development Training Working Group
(GTDF) of XBRL Spain

• The Development Training Working Group of XBRL
  Spain was set up as part of the initial design of
  the Spanish Jurisdiction. It was chartered to
  contribute to XBRL success in Spain acting as a
  risk reduction tool for XBRL early adopters
• GTDF is the Spanish acronym of this group, just
  in case you spot it in XBRL Spains papers
• Our role is to identify best (or bad!) practices
  to be adopted (or avoided!) in XBRL-intensive
  projects. Focus on training was expected to be a
  major risk reduction activity

3
About this presentation

• It reflects the authors view on XBRL versioning,
  trying to convey the lessons learned working with
  the XBRL users, both business and technical
  experts at Banco de España (the Spanish central
  bank) along the last 18 months, and also with the
  international experts working in the COREP
  project. It is not a formal position of Banco de
  España on the subject
• It was formally approved GTDF in November 2005,
  and it is an input document for further work on
  versioning by the GTDF, as part of the current
  effort to develop a life-cycle methodology for
  XBRL Value Chains

4
The instant success of XBRLin Spain

• Since it was set up in April, 2004, the Spanish
  Jurisdiction has been pushing the adoption of
  XBRL with so much success that
• Since June, 2005, ALL the enterprises traded on
  Spanish stock market report their financial
  status to CNMV (the Spanish stock exchange
  regulator) using XBRL. The CNMV publish in its
  Web this reports as soon as the XBRL instances
  are validated
• Since June, 2005, financial institutions legally
  operating in Spain can report to Banco de España
  their financial status using a taxonomy based on
  IASB-IFRS. This is the second taxonomy that Banco
  de España has delivered to production status in
  one year. And there are several in the pipeline
• The project COREP, leaded by Banco de España and
  aimed to define an European-wide base taxonomy
  for bank risk reporting to supervisors (in
  accordance with Basel II), encouraged XBRL
  community to standardize the usage of Dimensions
• So, why are we so worried about versioning now?

5
Versioning is about keeping the XBRL promise

• From business users perspective, XBRL was bought
  in as a solution to flexibility required by
  financial reporting
• Regulators, like CNMV and Banco de España, need
  to adapt the reporting laws and by-laws to catch
  up with business practices and new financial
  services that could impact on investors trust.
  And they need to do it without adversely
  impacting the investments on information systems
  of running companies
• Organizations reporting their financial status to
  regulators need to be able to quickly adapt their
  reporting systems to changes in regulation
• As we are already running XBRL reporting chains,
  the business users are beginning to ask Hey
  folks, how do we change this now?

6
Expectations on XBRL Versioning are high

• Our business users expect that introducing a
  change to a XBRL-enabled reporting chain should
  be an easy (or, at least, fast) task something
  that can be done in few days
• And we, the XBRL community, need to satisfy this
  expectation that was created in the old times of
  Charlie Hoffmann, when we were writing taxonomies
  with a text editor, and it seemed that financial
  people and computers could read and write the
  same XML files so future changes will be easy to
  do
• But
• What are the implications of a business user
  change request in an already running XBRL
  reporting chain?
• What could happen if XBRL cannot fit the above
  expectation, no matter if this is a fair one?

7
An informal SWOT Analysis of XBRL Versioning

• Strengths
• XML is probably the best foundation for
  versioning available
• Users expect XBRL value chains to be easily
  adaptable to business needs, and are betting on
  it
• Weaknesses
• Users expectations on XBRL adaptability could
  have gone beyond of what can be delivered in
  reasonable time
• Opportunities
• A practical solution to XBRL versioning will
  consolidate XBRL position, probably for many
  years
• Threats
• Failure to provide a good versioning solution
  would severely harm XBRL future
• Regulators can be tempted return to pure XML
  solutions
• The business potential of XBRL reporting chains
  will never realize if cost of versioning to third
  parties (analysts, rating agencies, ) is higher
  than current expectations due to complexity of
  solution

8
XBRL Versioning is not an obvious concept

• Are we sure that a technical solution documenting
  some changes to be applied to an existing DTS to
  achieve the next one would solve the problem that
  business users call versioning?

9
XBRL Versioning is not an obvious concept

• From business user point of view, XBRL versioning
  is ALL what is needed to run an improved version
  of a XBRL reporting chain
• New reporting needs (or problems in existing
  reporting chain, including performance related
  ones) have been identified and documented as
  change requirements
• The identified needs have been reflected in an
  improved DTS
• When required, the improved DTS has been approved
  by proper Jurisdiction, ideally after rigorous
  testing. In some cases, even enacting legally the
  changes should be done at same time
• The automated systems in senders and receivers of
  XBRL instances have been adapted to, and/or can
  coexist with, the improved DTS. The time required
  to implement the adaptation should span few days
• A technical solution to standardize the changes
  to be applied to an existing DTS to achieve the
  next one only address point 2 above. Point 3
  calls for an improvement of our approval
  processes.
• But if we cant provide a good framework to allow
  Point 4 to be feasible, XBRL community will be at
  risk of being blamed by business users of not
  being able to solve the versioning issue

10
XBRL Versioning Where are we targeting our
effort?

• Our feelings were mixed with regard to on going
  effort on Taxonomy Versioning requirements when
  we approved this presentation
• The use cases seems very good from the conceptual
  point of view. Some of them even reflect real
  problems we face recently
• But arent they assuming a hand-made approach to
  taxonomy writing and maintenance? This manual
  process is (should be?) almost gone
• At that time, we were tempted to say that the
  users that the IWD was talking about were, in
  fact, the existing programs for taxonomy edition!!

11
Versioning XBRL Does taxonomy versioning makes
sense?

• The impressive work conducted by IASCF XBRL Team,
  summarized in a huge Excel spreadsheet, raises
  even more doubts about if a versioning approach
  limited to the technical problem of how to
  document the changes to a DTS would be the right
  answer to XBRL versioning problem as business
  user perceives
• How to avoid regression problems?
• How to assure business coherence across versions?
• How to assess the impact on preparers and
  receivers automated systems using existing
  version of a taxonomy?

12
Versioning XBRL Two taxonomy versioning
technologies competing to save the day

• With so fuzzy scenario, the logical result is
  that we had to two competing approaches to solve
  the taxonomy versioning issue
• The syntactic oriented approach Lets DTS files
  speak by themselves, and use existing XML (or
  pure text CVS like-) versioning tools to extract
  the textual differences
• The semantic oriented approach Lets express the
  differences between two successive DTS, using
  something like RDF, to be able to understand the
  business meaning of differences
• This conflict is now frozen, but not gone

13
XBRL Versioning Can the business users
requirements help to select one of the two?

• Two years ago, what business users claimed was
  When will we have a workable taxonomy editor?.
  Now that they have several editors to choose
  from, taxonomies are quickly becoming for them
  software artifacts of their XBRL value chains
• Compliance of XBRL 2.1 Standard, and even most of
  FRTA specifications, are taken for granted and a
  tools responsibility
• Most of them have the same interest about
  syntactic (or semantic) aspects of taxonomies
  than a typical Access user in digging into the
  SQL generated for the database server none
• What the business user would say us, if they
  could understand the question -), is Do it as
  you want, as far I can do my changes with an easy
  to use tool, and my technical people cant say me
  We dont know how to apply the changes that the
  tool introduced in the DTS to our systems. And,
  please do it now

14
XBRL Versioning What are the current and future
roles of taxonomies in value chains?

• Surprisingly, this lack of answer can help us a
  lot
• We can expect that as soon as XBRL consolidates,
  only tools and very few experts with naked eye-
  will be interested -and able- in reading XBRL
  taxonomies and instance files
• Former role of taxonomy for business users as
  vehicle to document unambiguously conceptual
  models representing a group of related reports,
  is no longer visible to business users
• DTS will become some kind of e-contracts,
  published through an XBRL Jurisdiction acting as
  QA and escrow body, expressing without any
  ambiguity a succession of agreements among the
  links of an XBRL value chain
• The main role you can expect to be played in near
  future by DTS is the automated generation of
  instance visualization, adapter software (stubs)
  to existing systems, and as testing resource for
  the XBRL value chains
• This implies that, to be useful to business user,
  XBRL versioning must be solved at value chain
  level

15
XBRL Versioning An alternate approach

• We believe that solving XBRL versioning problem
  at value chain level should be based on top of a
  metamodel of current standard, shared by any XBRL
  enabled tool, or process, required to build and
  maintain the value chain
• The metamodel only need to extend the object
  model of current standard to provide explicit
  support of life cycle of DTS concepts
• Tools based on this metamodel could exploit the
  advantages of semantic versioning, without RDF
  complexities, as minor changes to the standard
  could allow DTS to contain a log of changes in
  metamodels terms (perhaps in another linkbase
  needed only by versioning enabled tools, for
  backward compatibility)
• And we shouldnt forget to revise our approval
  processes to check if we are agile enough when
  dealing with corrective changes

16
XBRL Versioning This alternate approach has
additional advantages

• In fact, currently exist some implementations of
  a metamodel of current standard every taxonomy
  editor must have one inside!
• An agreement on a common metamodel for versioning
  of XBRL 2.1 DTS, perhaps expressed in XMI, could
  cause some positive side effects
• If tools share the metamodel, the tools makers
  will send a clear sign of maturity to business
  users about securing their investment on tools
  and derivations from published taxonomies
• If the metamodel were expressed in XMI, we will
  provide interoperability with UML tools. This
  should make life easier for technical users
  implementing the XBRL adapters to operational
  systems
• Last, but not least, the metamodel would act as
  bridge to interoperability with what we call
  adjacent standards like SDMX. So, XBRL could
  play the role of hub standard for all the
  economy related standards, securing his current
  position

17
Thanks for your attention

• Questions?
• (shy people can mail to cesar.perez-chirinos _at_
  bde.es)