Practice Working Groups

Circulation of this Internal Working Draft is restricted. Other documents may supersede this document. Recipients are invited to submit comments to bpb@xbrl.org, and to submit notification of any relevant patent rights of which they are aware and to provide supporting documentation.

Abstract

The charter of the Best Practices Board (BPB) explains that the BPB will actively manage the production, dissemination and continual improvement of work products that describe methods and processes for successful development, implementation, integration, maintenance and usage of XBRL specifications [CHARTER]. The charter goes on to explain that the BPB will charter ad hoc or permanent Practice Working Groups (PWGs) as it determines to be necessary to develop work products. The Interim Best Practices Board has drafted this framework with four permanent PWGs and proposed an overall schedule of work products; this document describes them. The charters of the PWGs will follow after this, and they may differ from the from this draft framework.

1. Introduction. 2

2. Project Management (PM) 3

3. Reporting Processes (RP) 5

4. Taxonomy Architecture (TA) 7

5. Vendor-to-Vendor Interoperability (VI) 8

6. Next Steps 9

Appendices

A Taxonomy Comparison Framework
B References
C Intellectual property status (non-normative)
D Acknowledgements (non-normative)
E Document history (non-normative)
F Errata corrections in this document

Figures

Figure 1 Some Past and Future Sample Topics and Work Products 2

Figure 2. Project Management proposed working group topics 3

Figure 3. Reporting Processes proposed working group topics 6

Figure 4. Taxonomy Architecture proposed working group topics 7

Figure 5. Vendor-to-Vendor Interoperability proposed working group topics 8

1. Introduction

The widespread use of the term “best practices” in business does not mean that any two people agree what it means. Fortunately, we can use a working definition that “practices” in the context of XBRL means “methods to maximize the business value of implementing or using the XBRL language”. The challenge to define and promote a “best” practice for a given combination of circumstances can be decomposed into three distinct activities:

1. Collecting and accurately describing existing practices.

1. Evaluating and suggesting effective practices for different situations.

2. Determining compliance with a suggested practice.

Collecting and accurately describing how XBRL is used in different projects is difficult enough for many reasons: geographic distribution, differing business goals, differing perspectives and incomplete or contradictory information from participants within a project. Yet it is much harder to empirically and objectively evaluate those practices with respect to costs and benefits and to build consensus across the many parties involved in the XBRL International community. Hardest of all is to verify whether a particular practice is or was actually used by a person, project, or system. While being able to verify compliance has great value, it is so hard to achieve that as a general strategy the BPB will build toward compliance, from more tactically achievable and useful goals. Therefore, the BPB has defined only two types of work product that a PWG can create for the BPB to approve:

2. Request for Comment (RFC): A document describing existing practices. This document is meant to be collaboratively created and contributed to over time; it may never reach a “final” state. There is value simply in collecting together the practices used in different XBRL projects. While it is best if it contains empirical analysis, no overall evaluation is expected.

3. Practice Note (Note): A document that suggests effective practices for defined situations, reflecting the consensus of the working group insofar as it represents XBRL International. A simple example of a Practice Note might describe suggested timing and methods for exposing an XBRL Taxonomy for public review. Avoiding scope creep on Notes is a much bigger challenge than for RFC’s that by their nature may legitimately expand and evolve in scope. As a general principle, the BPB intends for a Note to offer one way of achieving a result, not a set of alternatives.

At this time there is no work product type for testing compliance with a suggested practice. The XSB can publish a RECOMMENDATION that has machine-testable sets of rules applying to software and computer files, but the BPB cannot. FRTA 1.0 is an example of an existing RECOMMENDATION that attempts to test whether certain practices are followed in a taxonomy, but it is not entirely machine-testable.

In addition to considering different levels of “force” for a BPB work product, there are many different types and levels of concern that arise in projects seeking to maximize the business value of implementing XBRL. Currently these concerns fall into four areas forming the four initial PWG’s.

· Project Management (PM): Organization and execution of large scale projects, especially taxonomy development and maintenance projects.

· Reporting Process (RP): Using XBRL appropriately across many organizations in a “supply chain”, taking into consideration all aspects of data exchange.

· Taxonomy Architecture (TA): Domain, Logical and Physical models to ensure reusability of the content of XBRL taxonomies.

· Vendor-to-vendor Interoperability (VI): Implementation methods that maximize the likelihood that XBRL produced by one vendor’s product will be interpreted correctly in another.

All four areas will be described in detail individually. Figure 1 is a grid containing sample topics and work products, both hypothetical and historical, to provide an overview.

Figure 1 Some Past and Future Sample Topics and Work Products

	RFC	NOTE	(Other)
PM	· Intellectual Property Considerations for Taxonomies · Getting Useful Taxonomy Feedback in a Public Review · Managing Vendors outside of a Taxonomy project · Methods of Assurance · Experience with Stakeholder Involvement	· Business Cases for Adoption · Managing Acknowledgement and Approval · How and Where to Publish a Taxonomy · Project publicity and communication · Source of authority about implementations · Change management · Private vs. Public Sector Development
RP	· Open vs. Closed Reporting Processes Impact on Architecture · Incremental versus “Big Bang” Adoption Strategies · Mandatory vs. optional adoption · Versioning Policies in Use	· Authenticating XBRL Filings · Transport Mechanisms · Timing XBRL Taxonomy Releases with Changing Reporting Standards · Rendering Processes · Post-XBRL Validation Steps · Software tools needed in addition to Taxonomy editors
TA	· Methods for consistency, comparability, and interoperability. · Methods for Describing Alternative Calculations in Taxonomies	· Financial Reporting taxonomy interoperability · XBRL data methods for analytic comparability · When to use Extensions instead of direct modification · How to apply patterns	FRTA 1.0 (REC)
VI	· Methods for serializing linkbases · Rendering methods in use · XBRL specifications implementation methods	· XML characters and multiline text · Keys to XLink implementation · Minimizing redundancy in linkbases · Pre- and Post-XBRL Validation	FRIS 1.0 (PWD)

Each section about a PWG below addresses these questions:

· How will the group improve the business case of adopting XBRL? There must be a demand for the information produced by the group and its benefit must clearly outweigh the effort and staff time contributed.

· What are the proposed work products of the group? What topics are most urgent and important, and how can they be described first as RFCs and later as Notes?

· Who are the participants? The members of the BPB are expected to take an active, leadership role in one or more working group. These are project managers, domain experts and architects on taxonomy projects, but the mix differs by group. Participants are expected to share in the work by contributing material to RFC. Where possible, participants should also contribute data on practices, for a Note.

Familiarity with the charter of the XBRL Best Practices Board (BPB) [CHARTER] and, to some degree, the current workings of XBRL International is assumed at various points this document, and where necessary, some understanding of the nature and function of XBRL Taxonomies.

2. Project Management (PM)

The PM group will improve the business value of XBRL projects by sharing project experiences and methods used to cost effectively organize and execute large scale taxonomy development and maintenance projects. The focus of RFC and Note work products will be on addressing topics that have historically resulted in adoption resistance, unanticipated costs, or other avoidable project issues.

PM Proposed RFC and Note work products

A set of critical topics has been assembled by the Interim BPB, a team that includes the authoritative insights of several taxonomy project leaders. The following list is in no particular order, although the first topic listed has generated considerable short‑term interest.

Figure 2 Project Management proposed working group topics

#	PM Topic	Topic Definition
1	Intellectual Property (IP) Policies	Publishers of taxonomies must follow intellectual property protection policies for their taxonomies and related work products that achieve many different goals: · Ensure that the legitimate IP of software vendors, consultants, standards bodies and other organizations are not infringed. · Ensure that all potential users are protected from commitments to incur intellectual property costs such as royalties. · Discourage organizations from claiming IP rights from which they would benefit unfairly from wider use of the taxonomy. Large projects face obstacles in meeting these goals: · For government institutions that have never before actively sought to encourage sharing and reuse of data or data definitions, these issues are likely to be unfamiliar. · Institutional arrangements to enable collaborative development vary across jurisdictions. · Different jurisdictions have different legal frameworks. For example, there is no equivalent to the European Union’s database copyright law in the United States; between developed and emerging economies there are often wide discrepancies in their treatment of the value of intellectual property. Without seeking to develop legal guidance, the PM working group could nevertheless usefully survey existing arrangements, sample agreements and record keeping in an RFC and, assuming that the different approaches can be objectively evaluated, publish a Note that suggests successful policies under different legal fact patterns.
2	Ownership and Sponsorship	There are several existing arrangements for the ownership of XBRL taxonomies. In every case where a regulator wishes to use a taxonomy, the regulator must be willing to own it, both in the sense of intellectual property ownership and in the sense of providing funding for continuing maintenance. Sponsoring the development of a taxonomy is not the same as ownership.
3	Stakeholder Management	Project leaders must not only bring together stakeholder communities to commit to taxonomy development, but also continually manage stakeholder engagement so that that by the time the taxonomy is finalized, the taxonomy still has the full support of those and if possible, additional stakeholder communities. While stakeholder support is generally a requirement for any Information Technology (IT) project, it takes on a specific meaning in the context of taxonomy development. In general, taxonomy projects consist of 1. A “core” taxonomy team, led by and having a majority of domain experts supported by XBRL technology experts, because experience shows that taxonomy development cannot be successful by domain experts alone. 2. A larger group of different kinds of stakeholders contributing in some way to development: software vendors, preparers, analysts, and others as appropriate. 3. An even larger community of external stakeholders consisting of interested parties and commentators. The skills and resources needed in taxonomy projects do not typically reside in a single existing organization, so that successfully executing the project also requires management of many contributors both paid and voluntary. Contract management and negotiation with the existing pool of XBRL expert resources, even if it only encompasses a participation agreement to address intellectual property considerations, can be an obstacle to successful project execution. Because everyone other than the core team is contributing on a voluntary basis, transparency of the taxonomy project is extremely important for building trust. The issues are similar to most open source development projects. The core team must receive and respond to timely, informed and substantive review from individuals who were not involved in development. Issues that arise in meeting this goal include: · Motivating reviewers, obtaining and receiving commitment from informed (but busy) reviewers. · Channelling input on specific elements or other taxonomy components and tracking whether they are acted upon. · Managing reviewer expectations as to whether their comments will be responded to or acted upon. · Timing the review period so as to allow adequate time to incorporate feedback before release. · Accommodating different institutions’ approach to review, which may be “interactive” (individuals providing a stream of point-by-point review items), “batch” (a group of individuals partitioning the review and collecting all review points together before returning them) or some mix of the two. The larger the taxonomy, the more challenging these issues. That can be partially, though not completely mitigated by using software supporting a workflow that integrates with the taxonomy. The focus of an RFC would be to analyze recent experience and highlight recent issues and successes. The evaluation of different approaches that would be needed for a Note will require more experience with published taxonomy reviews.
4	Role of XBRL International (XII) Acknowledgement and Approval	When publishers post a valid XBRL taxonomy on the XII web site, users, potential users and vendors of XBRL enabled software benefit from its accessibility and widespread availability. This has indirect benefits to the publisher of the taxonomy because the more users of the standard, the greater its value and the lower the long term cost of implementation. This is the basic purpose of the relatively simple process to obtain XII Acknowledgement. In spite of this, questions remain as to motivations and appropriate timing of Acknowledgment relative to publication of a taxonomy. A short Note could address this topic. The process by which publishers self‑certify their taxonomies with respect to the criteria of the Taxonomy Recognition Process (TRP) has a cost-benefit equation that is harder to justify, particularly since some of the key technical rules in XII’s FRTA 1.0 recommendation are in need of removal or update to maintain their relevance given the current suite of XBRL Specifications (see Section 4 below, “Taxonomy Architecture (TA)”). Also, even though it should be obvious that for some communities, the XBRL data in instances is of greater interest than the taxonomy, and no XII process exists for acknowledging or assisting users to find these data streams. A Note would be useful in communicating a roadmap for how and when these anomalies will be rectified.
5	Impact of Jurisdictional Acknowledgment and Approval	The taxonomy recognition process used by XBRL International is also applied, with variations, at the jurisdiction level. An RFC comparing results would be useful.
6	Strategic Adoption Issues	Adoption of XBRL taxonomies is never accidental. Adoption results from influential people and institutions having long term goals that are enabled by, among other things, open data standards. Even after leaders become aware of and advocate adoption of XBRL, other parties must either be directed to take mandatory action or persuaded to take voluntary actions. It is helpful, though not always necessary, for authorities to develop value propositions for a variety of different interests so that the benefits can be articulated and adoption to take place. There have been enough regulatory adoptions of XBRL now that a useful RFC could compare and contrast the nuances of: · Directed models such as the FDIC or Banco de España implementations. · Negotiated models such as the Netherlands’ compact. · Voluntary models such as the SEC’s Voluntary Filing Program or UK Companies House.
7	Relationship to Regulatory Frameworks	Projects basing an XBRL taxonomy on a regulatory or other framework face particular challenges: · The participation or leadership of the private sector in the implementation of a taxonomy reflecting a regulatory framework may cause confusion over the legitimacy and authority of the taxonomy’s contents. For example, this may lead to some parties incorrectly assuming that a taxonomy reflecting a particular set of Generally Accepted Accounting Principles is actually an authoritative disclosure checklist when it is not. · Identifying the potential and legitimate sources of change, anticipating these changes, determining how these changes will be reflected in a timely fashion in the taxonomy, and who bears the cost of such changes. The alternative positions and responses of different parties would be appropriate for an RFC.
8	Need and scope of Preparer and Vendor Guidance	A taxonomy based on XBRL requires documentation for preparers of business reports using that taxonomy, and documentation for software vendors seeking to enable their products to effectively use the taxonomy. Similar documentation has been developed for a variety of projects, generally covering the same topics (XBRL contexts, data types, taxonomy extensions, etc.) but often taking very different strategies for covering the technical details of XBRL itself, or its approach to guiding preparers as to how to choose software tools appropriate for their needs.
9	Change Management, Project Communication and Publicity	Taxonomy development projects are usually a part of an overall change from a heterogeneous or paper-based business report exchange framework, to a uniform taxonomy and an increased orientation to data over narrative. Therefore, taxonomy projects have a special need for simple, easily understood messages for the public, and this communication is a key aspect of successful adoption.
10	Business Cases	XBRL projects are undertaken in variety of situations and business cases. For example, the business case made by a statistical data collection agency in a small economy with an existing data collection infrastructure may be quite different from the case made by a securities regulator whose scope is international with a diverse set of methods. The business case is vital to have before a taxonomy has project has begun, to develop a community and obtain the sponsorship and funding. Communication methods, internal marketing, and external marketing materials have common features no matter the jurisdiction.
11	Integration with Business Intelligence (Analysis) Environment and Users	While the adoption obstacles for XBRL are normally thought of as associated with reporting entities or preparers, experience shows that an existing infrastructure or environment of analyst consumers of the data may also present adoption obstacles.

PM Participants and Leadership

Leadership of the Project Management practices working group should be drawn from experienced managers of XBRL implementation projects, with responsibility for some of the topic areas listed in Figure 2. For further qualifications refer to Section 3 (“Composition”) of the BPB Charter [CHARTER]. Participants should have expertise in one or more of the topics or an ability to contribute to a work product.

3. Reporting Processes (RP)

The RP group will improve the business value of XBRL projects by developing a vocabulary and structure for describing the reporting processes that are the necessary complements of XBRL taxonomies. Broader understanding of these processes will help to make XBRL appropriately used across many organizations in a “supply chain”, taking into consideration all aspects of data exchange.

RP Proposed RFC and Note work products

Figure 3 Reporting Processes proposed working group topics

#	RP Topic	Topic Description
1	Open and Closed Reporting Processes	One of the most fundamental questions that a data collector using XBRL must decide is the degree to which sharing of the data is important. Many taxonomy architecture decisions are determined by more fundamental process architecture requirements that determine whether the reporting processes are closed or open: · Closed: pre-registered submitters, generally no taxonomy extensions, anticipating only a single target database and minimal concern as to how the data will be shared beyond that database. The US FDIC system’s CDR (Central Data Repository) is an example. · Open: any company can produce instances, taxonomy extensions are allowed, and the instances are distributed widely to be incorporated into any database. The SEC’s EDGAR Voluntary Filing Program is an example. An RFC would identify these characteristics and indicate the business cases that would apply to these very different situations.
2	Processes for Identifying Filers and Filings	Detailed, line item level information cannot be effectively shared unless a more basic issue is solved: how are filers and filings identified? Maintaining a registry of filers and tracking the correct versions of filings for a filer is a necessary component of every data collection system but there is no standard way to embed this identifying information into XBRL instances. Complicating factors include: · Different ways of grouping information into instances. · Different instances covering different periods with the same end date (yearly, quarterly, monthly, etc.) · Individual “solo” company or multiple submissions “consolidated”. · Tracking individual company extensions referenced by each instance. · Checking the consistency of the instance’s intended scope with its context elements. A survey of requirements could result to a Note that would suggest specific ways of identifying the scope of an instance.
3	Authentication and data integrity of submissions into gateways	Regulators have implemented various processes for filers to certify their documents and for recipients to authenticate them. This ranges from digital signatures at DCCA, the UK IRmark, multiple methods in Australia, and client authentication at the TSE, while EDINET at this time has none.
4	Instances: Archival or Transmission	XBRL instances are treated in some systems as ephemeral messages and in others as archival documents. This impacts a variety of process design issues: · Identifying the “submission of record”. · Distinguishing the original, copy, transport, shredded, and rendered versions. · Determining the degree of control that a submitter should have over rendering and formatting.
5	Post-XBRL Validation	A filing submitted to a data collection authority may need several levels of validation. Because XBRL instances are a restricted form of XML Schema instances, not even all of the validation available in XML Schema is available to XBRL taxonomy developers. XBRL specifications that have reached RECOMMENDED status provide validation such as: · Some consistency checking between units of measure and numeric data types · Consistency checking of arithmetic consistency. · Consistency checking of multidimensional data. · Primitive data type testing (dates, strings, monetary, enumerations). Forthcoming XBRL specifications may provide additional validation, but at this time, additional validation must take place outside of XBRL, such as: · Restrictions on units of measure. · Detection of duplicate or inconsistent facts. · Consistency checking on the names or structure of entities or periods. · Consistency checking across time periods or business segments. These additional validation processes are necessary. Even if the specific validation rules for a given regulator are confidential, a survey of languages and methods would be an appropriate RFC.
6	Versioning Policies	The XII Versioning Requirements make clear that no matter what technical standard is used to express versioning information, it is also necessary to have versioning policies that determine what kinds of events should result in the publication of new versions of taxonomies. The importance of versioning policies arises from the number of different reporting process participants impacted. Their complexity arises from the number of possible different sources of changes. Another complexity arises from multiple taxonomies; the possibility of early adoption of an accounting standard by some filers and not others means that different versions of a taxonomy may be acceptable at the same time. The empirical work needed for an RFC, covering projects such as the Dutch Taxonomy Project (NTP), Companies House Audit Exempt (CHAE), US FDIC and other taxonomies, has already been done as part of the Versioning requirements analysis.
7	Additional Software Features and Functions	As outlined in the other topics for the RP working group, the publication of a taxonomy implies that software must support functions beyond editing of the taxonomy. For a taxonomy publisher, there will be web servers and gateways for accepting reports, but also: · Tracking change requests and changes to the taxonomy. · Regression testing of the new taxonomy against previous design rules, sample instances and other tests. · Managing references to and from authoritative literature. An RFC could consist of an inventory of software functions needed for reporting and data collection processes, as well as the functions needed by a taxonomy publisher.

RP Participants and Leadership

Leadership of the Reporting Process practices working group would ideally be drawn from business or regulatory leaders with responsibility as process architects. Experienced managers of processes that include an XBRL reporting component, with responsibility for some of the topic areas listed in Figure 2. For further qualifications refer to Section 3 (“Composition”) of the BPB Charter [CHARTER]. Participants should have expertise in one or more of the topics or an ability to contribute to a work product.

Some of the topics in this working group have confidential aspects to them, as for example the details of how instances are validated within a regulatory system, or software features and functions. Therefore, in this group perhaps more than others, it may be necessary to rely on XII staff or others who can sign non-disclosure agreements.

4. Taxonomy Architecture (TA)

The TA group will improve the business value of XBRL projects by providing detailed analysis of domain, logical and physical models of taxonomies and objectively evaluating their impact on the reusability of their content.

TA Proposed RFC and NOTE work products

There is currently a joint project for “Interoperable Taxonomy Architecture” among the Japan FSA, US SEC and IASCF that developed the Taxonomy Comparison Framework duplicated in Appendix C. This project will identify, survey and compare, respectively, the EDINET, US GAAP, and IFRS taxonomies. Its focus is on architecture, not content. The majority, though not all, of the items within the Comparison Framework are relevant to the TA practice working group. At this time the Interim BPB intends to wait until the interoperable taxonomy architecture project has released its results before convening the TA working group.

Figure 4 Taxonomy Architecture proposed working group topics

#	TA Topic	Topic Description
1	Overview of Design Layers	Discussions of data architectures are clearer when a distinction is made among different layers: · Domain (Content), which includes concerns such as the organization of basic financial statements versus notes, organization for industries, and handling of references to authoritative literature. · Logical (Sometimes called “patterns” or “styles”), which binds the different parts of the domain content into logical structures that focus on the logical constraints and not XBRL syntax. · Physical (Sometimes mistakenly called “architecture”) which details how the logical model is modelled within the constraints of XBRL and how it is serialized into files. An introductory Note from this working group could prevent confusion about its other work products.
2	Tables, Tuples; logical modelling of otherwise identical domain content	The circumstances and needs leading to the choice of different logical structures for repeating and multidimensional data points, or multiple levels of aggregation detail, should be articulated for the community to make informed choices.
3	Usability of data for analytic comparability	Principles to follow to improve the usability of XBRL data sometimes, though not always, are encoded into the taxonomy. A prime example of this is the use of Sign conventions and their relationship to the “credit” and “debit” balance attributes of monetary items. Another example is how to model alternative aggregations.
4	Style Guides	A Note could explain how the Domain, Logical and Physical design choices should be enforced in a Style Guide for taxonomy developers, and associated post-XBRL validation steps.
5	Displaying Taxonomies with Matrix structures	Conventions by which taxonomies using matrix structures (whether encoded using tuples or Dimensions) should be displayed would help domain experts to understand the content of taxonomies.
6	Impact of Generic Links Specification	Generally, new XBRL specifications may impact the design choices made in designing taxonomies. The Generic Links specification will be updated in 2008.
7	Impact of Inline XBRL Specification	Generally, new XBRL specifications may impact the design choices made in designing taxonomies. The Inline XBRL Specification is expected in 2008.
8	Impact of Versioning Specification	Generally, new XBRL specifications may impact the design choices made in designing taxonomies. The Versioning Specification is expected in 2008.
9	Impact of Formula Specification	Generally, new XBRL specifications may impact the design choices made in designing taxonomies. The Formula Specification is expected in 2008.
10	Impact of Rendering Linkbase Specification	Generally, new XBRL specifications may impact the design choices made in designing taxonomies. A Rendering Linkbase Specification is expected in 2009.
11	Taxonomy versus Instance Interoperability	The interoperability of taxonomies is a much more difficult problem to solve than the interoperability of instances, because the laws and regulations underlying taxonomies may be completely different and it is virtually impossible to anticipate all cases. By contrast, for a given instance or set of instances, the problem is more narrowly scoped to just the concepts used in the instance, and there may be supporting information that has already provided some of the domain mapping.
12	Taxonomy linking	Some XBRL jurisdictions have already developed separate taxonomies with overlapping subject matter. Filers using two different taxonomies for instances with the same information are unlikely to get any benefit from XBRL. Linking the taxonomies may be a necessary prerequisite to subsequent sponsorship and development of a single taxonomy encompassing both.

TA Leadership and Participants

Leadership of the TA practices working group would ideally be drawn from technical leaders with reporting content or financial analysis expertise, and direct participation or leadership of taxonomy development efforts. For further qualifications refer to Section 3 (“Composition”) of the BPB Charter [CHARTER]. Participants should have familiarity with the development of XBRL taxonomies from a domain perspective.

5. Vendor-to-Vendor Interoperability (VI)

The VI group will improve the business value of XBRL projects by identifying and sharing implementation methods that maximize the likelihood that XBRL produced by one vendor’s product will be interpreted correctly in another. A specific goal will be to encourage user awareness that should, in turn, enhance vendor awareness.

VI Proposed RFC and NOTE work products

It may be difficult to find an appropriate scope for RFC and Note work products; some topics seem almost trivial even if they cause products to interpret data differently and therefore defeat interoperability. Also, related topics should be treated differently if some areas are unambiguous and others the subject of discussion. For example, there is a difference between correctly implementing XLink as opposed to the alternatives for efficient XBRL Linkbase Serialization. Other topics seem so extensive that they may be more properly the subject of XSB activities. The Interim BPB believes that it is better to deal with small issues quickly. Some of these issues are urgent because users generally make no distinction between the software product and the taxonomy, and when there are interoperability issues they reflect badly on XBRL International.

Figure 5 Vendor-to-Vendor Interoperability proposed working group topics

#	VI Topic	Topic Description
1	XML Characters	Products differ in their treatment of whitespace; non-numeric XBRL elements should be read without stripping whitespace. Some products have limits on the length of string content, which causes them to be unable to correctly process XBRL taxonomies and instances.
2	XLink Implementation	The XBRL conformance suite has few tests that specifically test compliance with XLink semantics. For a specific example, linkbases in which the same value of the XLink “label” attribute appears in multiple extended links are incorrectly read by some products. Like many of the interoperability issues this arises because of incorrect implementation of XLink, and a conformance suite for this is needed.
3	XML Schema Validation	The lack of interoperability between different major vendors’ XML Schema validation leads to many interoperability problems, and issues such as the way that different validators handle repetition counts other than 0, 1, or unbounded can have dramatic impact on performance. Examples include: Some products have limits on the length of string content, which causes them to be unable to correctly process XBRL taxonomies and instances. The decimal values of the order attribute in linkbases are XML Schema compliant when they appear in scientific notation, but most products throw an error when this is encountered. Products differ in their treatment of whitespace even though XML Schema defines this precisely; non-numeric XBRL elements should be read without stripping whitespace. Raising awareness of the correct way to encode and decode whitespace characters both from the user and software vendor perspective is necessary given the recent reported experiences.
4	XBRL Validation (DTS)	The opening and processing of a Discoverable Taxonomy Set is another common area in which current products fail to read and write interoperable files. Implementation hints, and possibly additional conformance tests, are needed. Somewhat different issues apply to taxonomy schemas and the core XBRL schemas as defined in the Specification.
5	Taxonomy Sizing	Taxonomies (actually, Discoverable Taxonomy Sets) are getting larger and will probably continue to do so.
6	XBRL specifications implementation in production software	Independently of problems with the underlying specifications, the XBRL specification itself is not always implemented correctly. Hints for vendors implementing XBRL output would help with many of these simple issues.
7	Precision, rounding, and units implementation	The semantics of the “decimals” attribute remain poorly understood because they are sometimes misunderstood as having a relationship to scaling or presentation. This is only compounded by the use of units of measure such as “thousands”.
8	Linkbase Serialization Alternatives	Empirically it appears that different products are more or less efficient with different linkbase serializations. Better communication on this subject would help taxonomy developers to choose serialisations that are less likely to cause problems.

Some of the topics in Figure 5 suggest an FAQ for vendors, a paper that documents common areas of inconsistency or improper implementation.

VI Leadership and Participants

Leadership of the VI practices working group would ideally be drawn from technical leaders with traditional software development experience as well as taxonomy development. For further qualifications refer to Section 3 (“Composition”) of the BPB Charter [CHARTER]. Participants should have technical expertise in one or more of the topics or an ability to contribute to a work product, particularly to the extent that they involve the creation of technical conformance suite materials. The pool of individuals with these qualifications may already be committed to the XII Base Specification and Maintenance Working Group, and so the role of the PWG may be limited to collecting less formal FAQ-like documents.

6. Next Steps

The BPB is expected to be formed and convene in mid-2008. The planned composition of the BPB is described in the Charter and Call for Applications. Practical, hands on implementation experience is emphasized and the following four competencies are targeted:

· Regulatory Reporting

· Programme Management

· Financial Analysis

· Software

The Interim BPB will charter working groups and begin work with existing resources immediately. All working groups will be chartered in 2008 and first RFCs are expected by 2009. By 2010, some of the RFCs should have matured into Notes.

Staff Resources will be allocated to the BPB working groups with an emphasis on staff to perform evaluations, and as the number of simultaneous tasks grows, a deliverables manager will coordinate timely delivery. Job descriptions for these staff positions are currently under development.

Appendix A Taxonomy Comparison Framework

· General information

· Taxonomy Owner

· Version of Standards/GAAP

· XBRL Specifications at last release

· Status

· Date of release

· Period of appliance

· Access to the Taxonomy

· Taxonomy Development Process Model

· Taxonomy Requirements

· Taxonomy Architecture

· Taxonomy Style Guide for Labels

· Taxonomy Data Model (Human Readable - PDF, Excel rendered version of the taxonomy structures)

· Taxonomy Testing Framework

· Taxonomy Review Process

· Review Period for Exposure Draft

· Taxonomy Supporting Tools

· Taxonomy Usage

· Taxonomy Stakeholders and Their Requirements

· Open vs. Close Reporting Cycles Usage

· Character of Taxonomy Extensions

· Content Coverage

· General Scope

· Industry Coverage

· Common Reporting Practice

· Detailed Statements/Disclosure Content

· Document Information

· Entity Information

· Linking with Other Reporting

· Architecture (base/core taxonomy)

· General considerations

· Taxonomy framework

· Naming Convention for Namespace URI

· Taxonomy design patterns

· Flat (open) tables (usage of tuple, if there is tuple in the taxonomy, name of the elements and possibility of elimination of the tuple)

· Hierarchies

· Intersection tables (movements)

· Dimensional patterns

· Taxonomy schemas

· Custom Data types

· Method for defining of element which contain text block

· Taxonomy linkbases

· Granularity of Extended Link Role (ELR)

· Custom arc roles

· Modularisation of linkbases

· Reference linkbase

· Method for classification of elements based on Accounting Standard and Common Practice

· Custom reference roles

· Label linkbases

· Custom label roles

· Documentation in label linkbase

· Presentation linkbase

· Calculation linkbase

· Definition linkbase

· New XBRL technologies

· Dimension

· Versioning

· Rendering

· Formulas

· Taxonomy Extension Guidance

· Documentation

· Rules for taxonomy extensions

· FRTA compliance

· Rules for adding node to presentation / calculation / definition / label linkbase

· Rules for including dimension in extended taxonomy

· Rules for relationship between extended element and authoritative reference

· Rules (restrictions) for adding of extended link roles

· Naming Convention

· Namespace Prefix

· Namespace URI

· Filename

· Taxonomy Preparers Guidance

· Granularity of instance document (by Statement, by report…)

· Rules for instance documents

· Rules for creating instance document with dimension

· FRIS compliance

· Contents of Entity Information

· Rules for Context ID

· Rules for Unit ID

· Pre-defined scenario

· Rules for describing “in millions”, “in thousands”

· Rules for Footnote

· How to crate multiple financial document from single issuer at the same time (series fund)

· Taxonomy Maintenance

· Trigger of Taxonomy Maintenance

· Expected Frequency of Taxonomy Maintenance

· Taxonomy Maintenance Process

· QA Process & Check Rules

· QA Criteria

· Strategy for Immediate Release

· Release timeline

Appendix B References

CHARTER

XBRL International Inc. "XBRL Best Practices Board - Charter"

(See http://www.xbrl.org/BPB/BPB-Charter-2008-03-03-Approved.htm)

XBRL 2.1

XBRL International Inc. "Extensible Business Reporting Language (XBRL) 2.1"
Phillip Engel, Walter Hamscher, Geoff Shuetrim, David vun Kannon, and Hugh Wallis.
(See http://www.xbrl.org/Specification/XBRL-RECOMMENDATION-2003-12-31+Corrected-Errata-2006-12-18.htm)

XLINK

W3C (World Wide Web Consortium). "XML Linking Language (XLink) Version 1.0"
Steve DeRose, Eve Maler, and David Orchard.
(See http://www.w3.org/TR/xlink/)

XML NAMES

W3C (World Wide Web Consortium). "Namespaces in XML 1.0 (Second Edition)"
Tim Bray, Dave Hollander, Andrew Layman, and Richard Tobin.
(See http://www.w3.org/TR/REC-xml-names/)

XML SCHEMA STRUCTURES

W3C (World Wide Web Consortium). "XML Schema Part 1: Structures Second Edition"
Henry S. Thompson, David Beech, Murray Maloney, and Noah Mendelsohn.
(See http://www.w3.org/TR/xmlschema-1/)

Appendix C Intellectual property status (non‑normative)

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to XBRL International or XBRL organizations, except as required to translate it into languages other than English. Members of XBRL International agree to grant certain licenses under the XBRL International Intellectual Property Policy (www.xbrl.org/legal).

This document and the information contained herein is provided on an "AS IS" basis and XBRL INTERNATIONAL DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

The attention of users of this document is directed to the possibility that compliance with or adoption of XBRL International specifications may require use of an invention covered by patent rights. XBRL International shall not be responsible for identifying patents for which a license may be required by any XBRL International specification, or for conducting legal inquiries into the legal validity or scope of those patents that are brought to its attention. XBRL International specifications are prospective and advisory only. Prospective users are responsible for protecting themselves against liability for infringement of patents. XBRL International takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Members of XBRL International agree to grant certain licenses under the XBRL International Intellectual Property Policy (www.xbrl.org/legal).

Appendix D Acknowledgements (non‑normative)

The editors thank the members of XBRL International for supporting the creation of this document, and for providing valuable feedback on internal drafts.

Appendix E Document history (non‑normative)

Date	Author	Details
7 April 2008	Walter Hamscher	Created internal working draft.
9 April 2008	Walter Hamscher	Updated internal working draft with input from Interim BPB members.
15 April 2008	Walter Hamscher	Updated to final version for distribution.

Appendix F Errata corrections in this document

This appendix contains a list of the errata that have been incorporated into this document. This represents all those errata corrections that have been approved by the XBRL International Interim Best Practices Board up to and including 09 April 2008. Hyperlinks to relevant e-mail threads may only be followed by those who have access to the relevant mailing lists. Access to internal XBRL mailing lists is restricted to members of XBRL International Inc.

No errata have been incorporated into this document.

Practice Working Groups

15 April 2008

This version:

Editors:

Contributors - Interim Best Practices Board Members and Staff:

Status

Abstract

Table of Contents

Appendices

Figures

1. Introduction

2. Project Management (PM)

PM Proposed RFC and Note work products

#

PM Topic

Topic Definition

PM Participants and Leadership

3. Reporting Processes (RP)

RP Proposed RFC and Note work products

#

RP Topic

Topic Description

RP Participants and Leadership

4. Taxonomy Architecture (TA)

TA Proposed RFC and NOTE work products

#

TA Topic

Topic Description

TA Leadership and Participants

5. Vendor-to-Vendor Interoperability (VI)

VI Proposed RFC and NOTE work products

#

VI Topic

Topic Description

VI Leadership and Participants

6. Next Steps

Appendix A Taxonomy Comparison Framework

Appendix B References

Appendix C Intellectual property status (non‑normative)

Appendix D Acknowledgements (non‑normative)

Appendix E Document history (non‑normative)

Appendix F Errata corrections in this document