Presentation and calculation linkbase limitations,balance and periodtype attributes,predefined pre-dimensional fact item period and entity,differences in design of specifications,syntax of instance documents,streamability and scalability,and even usage of XLink,are examples advocates raise when discussing a most feared activity:upgrading the specification to a version 3.0.We will try to weigh different views expressed (often with passion)in our munity and attempt to provide a more balanced opinion facilitating much needed discussion on this all important ic.

A holistic overview of the problem would require us to verify at least the following aspects:reason for changing or keeping the existing specification,spe and process of upgrade and impact on various stakeholders including st factors.Preferably each of these shall be supported by balanced and logical arguments,rather than personal preferences.

Therefore,nsidering reasons for changes,we should probably look at the closest unterpart to the XBRL international anisation:the Automobili lambhini s.p.A.pany.Someone admiring in the early tuscany sun the glistering Giallo Midas Pearl Effect lour hood of lP-560Gallardo would probably doubt whether anything better can or should be designed.But then came the Nero Noctis lour hood of lP-640murciélago followed by the Grigio telesto lour hood of lP-700Aventador and all the Porsches,Ferraris,mclarens,Bugattis,Nobles, Paganis,Koenigseggs not to mention Aston martins simply vanished in embarrassment.This excellent parallel tells us that there does not need to be any reason for improvement of what is already almost perfect.

However some may object and raise trivial reasons like limitations of the XBRL 2.1specification,specifically in relation to fixed attributes (like periodtype or balance),calculation linkbase not supporting cross-ntext or cross-period functions, presentation linkbase allowing only hierarchical structures,the XML with XLink mechanisms,syntax of dimensional information in instance documents (1 fact 1 ntext through the ntextref attribute).Another reason uld be the requirement of nsolidation of modular specifications,that present a number of innsistencies in definitions and obsolete syntax impacting the new modular specifications.Yet another reason would be to improve performance of validation and processing of instance documents or navigating the syntax of tuples,in parison to typed dimensions likely the most ntroversial and hot ic on the nsortium’s mailing lists.Some specifications like Generic links,while providing powerful functionality,are often reported as nfusing for users or vendors,due to their immense flexibility.Other critics may bring up developments in fields related to XBRL,including ontologies or interoperability with other standards like ISO 20022,SDMX or ARD,all of which undergo periodic review.Yet another group will argue,that whilst the initial purpose of XBRL was to address financial reporting,present application prevails in banking,tax or other reporting domains and that these domains use different reporting models requiring different syntax.Some would nclude that the above,despite initiatives like Abstract Model or API signatures,raise sts of XBRL developments and hence impede adoption of the standard.

Opponents of the upgrade would often use the st-to-benefit ratio highlighting the sts imposed on filers,software vendors and regulators.Others would state that XBRL is a working solution applied for a number of productionstage,mandatory programs hence technical updates are of lower priority pared to adoption.

While the above list is not exhaustive,what is clear from this overview,is that arguments “pro”focus on the technical side,while arguments “ntra” highlight the adoption side of the standard.However,as we will present in the next part,XBRL international has a number of solutions to address the potential adoption risk and stakeholders engagement in the upgrade procre.reverting to our supercar allegory we uld nclude,that it is inevitable,that we will buy a lambhini at some point of time.However,taking into acunt our family reaction when they find out that we sold the house and spent some 400thousand usD on a ncept that nsumes only 17.2l/100km (16.4mpg),we should very carefully nsider our migration strategy.

Firstly,XBRL international has already foreseen and established a due process of developing(and updating)specifications and this process has quite suessfully worked for all to-date XII products.specifications development starts with a llection of requirements,works its way through working group drafts,internal working drafts,public working drafts,candidate remendations,proposed remendations and finally ends up as remendations.At each stage products are nsulted with various groups of stakeholders and from public working draft onwards always exposed publicly for ments and feedback,further addressed by the relevant Working Group supervised by the standards Board.Any issues arising in the process are discussed during open (to nsortium members),regular calls or can be submitted (by anyone)electronically or in person during nferences.the process,while sometimes painful and lengthy,ensures that the final product is a nsensus of all participants.What this process can’t do is to assure relevance at a later point of full deployment (usually half a decade in the future), or speak for use cases and stake holders who will only arrive closer to deployment time.It also doesn’t insulate stakeholders from seeing standards emerge in parallel from separate anisations (such as dimensions from OMG and SDMX,formula and rules from ISO,OMG,W3C,ETC).

Sendly,thinking about the spe of the upgrade the most often mentioned terms are nsolidation,simplification and increase of nsistency.At present major specifications include:XBRL 2.1(2003),Dimensions 1.0(2006),Formula 1.0(2009-2011),Versioning (2013),inline XBRL (2011),Generic links (2009)all of which include some errata.These products were developed by various volunteer staffed working groups with different experts ntributing to initial assessment of requirements and design of syntactical and semantical solutions.Some say that as a result we have an engine from Kamaz,chassis from Ferrari, mirrors from lambhini,paint from shelby Gt, brakes from Fiat Cinquecento,all of that assembled in the dark with the final look of a holden UTE.All we know it is called XBRL.

Therefore the major activity nsidered as specification upgrade is renciliation between varying syntactical solutions applicable through different specifications,to taxonomies and instance documents.Updates may also be required in relation to newer versions of external ponents(XSD 1.1,XPATH 3.0).Simplification of syntax, especially in relation to instance documents,and inrporation of Abstract model ncepts into the syntax are very likely candidates for the upgrade.Detailed changes however are not yet known or decided.Should we as a munity choose to upgrade,potential changes will be expected to be thoroughly discussed by the relevant working group and publicly nsulted.

The final aspect of upgrading to 3.0,raised at the beginning of this article,is the impact on the XBRL standard’s users including filers,software vendors and regulators or financial standard setters.The ic bees more sophisticated since several aspects impact st analysis,like:spe or level of integration of XBRL within the anisation, specifications used by the taxonomy,maturity and functionality of the software implemented and other.It is however certain that changes to the specifications mean changes to the XBRL software (validators,reports creators,mappers) and in nsequence to any system using such ponents (the databases,repositories,BI and analytical systems of the nsumers).Furthermore changes introduced to the specification are more than likely to impact syntax and architecture of taxonomies resulting in re-development sts and impacts on existing projects,products and developments must be nsidered as an inherent part of the migration strategy and must not be ignored.

Among solutions easing the st burden the nsortium may nsider:patibility of instance documents and taxonomies (whilst challenging this may,depending on syntactical changes,be feasible and valuable for the munity),parallel maintenance of the existing set of specifications for existing users with long-term transition table,extended development and nsultation timeline and more feedback llection points along the process.All these will not necessarily remove the sts but as with any change they should support migration and will allow anisations to plan their strategy.Sadly such solutions will not work for purchasing the Aventador so if you want one you will still probably need to sell your house.

While opinions,evaluations of reasons,assessments of sts and impacts and other ics raised above are not a plete list and are more than likely to differ,starting the discussion early and planning the upgrade well ahead will give us more leeway to prepare for the inevitable changes.

Greatness is not where we stand,but in what direction we are moving.We must sail sometimes with the wind and sometimes against it but sail we must,and not drift,nor lie at anchor (Oliver Wendall Holmes).Therefore whether we are looking at two sides of the same in or not,there is a need to look.Perhaps we need an XBRL unterpart of lambhini sesto elemento,a lightweight version of the standard,similarly like the sGml munity which developed XML,which led to the global adoption of the latter?remember suessfully fixing a problem with a defective product may lead to higher nsumer satisfaction than that experienced where no problem ourred at all.

Acknowledgments in alphabetical order:John Dill,Herm Fischer,Masatomo Goto,Bartosz Ochocki,Maciej Piechocki.

原文链接：