XBRL International Technical Working Group and Work Product Process – 2007-04-17

This document has been approved by the XBRL International Standards Board and the International Steering Committee. It has undergone extensive review and revision by the XBRL International Standards Board (XSB). Consultation drafts were widely distributed to the XBRL membership to provide the opportunity for comment and feedback and revisions have been made based on feedback received from the membership. The technical working groups operated over a six month period, following the processes in the consultation draft and appropriate changes were made to the final version as a result of that practical experience. It is the primary process document governing the operation of the technical working groups of XBRL International Inc.

1 Background

In 2002 XBRL International Inc. (XII) formally adopted a set of processes for production of its work product. This was developed from a large set of inputs and reflected the best belief at the time of how things should work.

Since then the organisation moved along producing work product somewhat in accordance with the ideas and processes documented in these documents and, indeed, created some additional processes for specific activities, notably the Taxonomy Recognition Process (for which a large amount of supporting documentation was also produced) and the Link Role Registry, which is a document that both defines the technical structure of the registry as well as the process by which entries are into it are developed and approved. The processes in this last document were modelled on the underlying set of processes from 2002.

With the formation of the XBRL International Standards Board (XSB) both the structure of Working Groups and the processes to be followed in the production of work product have been reformed. The concept of ad hoc Working Groups (WGs) organised around specific projects has gained favour requiring a complete re-look at all aspects of both technical group lifecycles and work product lifecycles. Underpinning this is the definition of the relationships between various technical groups and other parts of the organisation such as XII staff, the XSB, the International Steering Committee (ISC) etc. This document defines a completely new set of processes, structures and relationships to enable XII to move into the next phase of its existence. It is prepared under the mandate of the XSB assigned to it by the ISC to define these.

2 Sources of input [1]

In addition to the previously mentioned documents, with, by reference, all the input sources used in their preparation, it has been instructive to look at the way other standards setting bodies are organised. Such organisations with a larger budgets and/or longer histories than XII have developed processes and organisational aspects that can be drawn upon and modified for XII use in the knowledge that they have been put into practice and functioned more or less effectively in the real world. Of course it is essential to recognise that XII is a different organisation with different dynamics and goals than such other organisations and those other organisations’ processes and structures cannot, or at least should not, be copied directly.

The following two organisations in particular bear certain resemblances to XII. OASIS (Organisation for the Advancement of Structured Information Standards) and the W3C (World Wide Web Consortium) in that they are both dedicated to the creation of “open standards”[2] related to computer data and meta-data representation etc. (although generally at different levels of abstraction from each other). Both are consortia that have a membership structure somewhat similar to that of XII (although definitely not identical). Also there are certain overlaps between the work of XII and these bodies as a result of their “playing in a related space”. Another standards body that is commonly encountered during the work of XII is the IASCF (with its board, the IASB) which has a set of formal procedures for its work product production and approval but is significantly different in both nature and stature from XII. It has therefore been found to have less relevance to the development of XII processes than the other two organisations mentioned here.

The primary documents that have been referenced from OASIS and the W3C are:

OASIS Technical Committees Process

and the

World Wide Web Consortium Process Document

3 Document structure

There are three main views of the subject matter of this document. They are as follows:

Organisational components and their interrelationships

This view addresses the different types of groups of individuals that participate in the technical development process and how they relate to each other. It includes the different types of Working Group (Permanent and Ad Hoc), other groups such as “Review Teams” (which is a new term that is coined to describe groups such as the LRRAG defined in the Link Role Registry document) and how they relate in their activities to each other and to other bodies such as the XSB, ISC etc.

Working Group life cycle and internal processes

This view addresses how Working Groups are formed, who participates in them and in what capacity, how their day to day business is to be conducted and how they are wound up when their work is complete. It also briefly addresses similar aspects for other groups of individuals who participate in the XII technical processes such as “Review Teams”.

Work Product life cycle

The output of the Working Groups is generally a “work product”. Each such work product goes through a set of stages. This view addresses those stages, and how work product progress between them.

4 Organisational components and their interrelationships

With the formation of the XSB the organisational structure represented in Figure 1 was approved.

Figure 1: WG Composition and Relationship to the XSB and the ISC

This structure provides the framework in which to understand the rest of this document.

It should be noted that the XSB derives its authority from the ISC and that the by-laws of the corporation make this explicit and, to emphasise that fact, use the term “ISC” to describe various activities and responsibilities that are actually discharged by the XSB. The remaining parts of this report are to be understood in that context. In general, responsibilities that will be discharged by the XSB are identified as such to make the operational aspects clear but in all such cases it is to be remembered that the XSB is simply acting in loco of the ISC. At times it is necessary to distinguish between activities and responsibilities that are discharged by the XSB or the ISC and this is done by use of the appropriate acronym where required.

An additional component to the XBRL International Organisational framework is a “Review Team” (RT)[3]. This is generally a small group of individuals with particular, focussed skills that review certain technical material as part of an approval process that is designed for that particular type of material. Specific cases known initially are for the Link Role Registry and for the Taxonomy Recognition Process. In these activities the RTs replace the LRRAG and the Domain WG respectively. RTs are appointed by the XSB and are answerable directly to the XSB. Their members serve at the pleasure of the XSB. The details of the functioning of these RTs are not addressed here but will be the subject of future revisions of the Link Role Registry and for the Taxonomy Recognition Process.

While this process imposes certain requirements on WG Chairs and Vice-Chairs, the XSB is committed to supporting the activities of the WGs and ensuring their success. This is achieved by expediting the addressing of requests and communications from the WGs; providing technical staff resources for liaison and guidance in the implementation of the processes and procedures wherever necessary, and proactive communication between the XSB and the WG leadership.

5 Definitions

This section provides definitions of terms that are used elsewhere in the document and should be referred to in order to understand the precise meaning where the terms defined herein are encountered.

a) “Charter” is the document that defines the terms of reference for a WG. It should contain at least the items included in the proposal to form that WG. See sections 6.2 and 6.11.

b) “eGroup” is an electronic discussion list owned and managed by XBRL International

c) “Entitled Person” means someone who is either an XBRL Participant or who has been deemed by ISC or the XSB to be entitled to the same privileges as an XBRL Participant in respect of the processes defined herein.

d) “IP Policy” is the XBRL International Intellectual Property Policy – see http://www.xbrl.org/legal/

e) “Leave of Absence” has the meaning defined in section 6.6.

f) “Majority Vote” is a vote in which the number of “yes” votes cast is greater than the number of “no” votes cast without counting abstentions. e.g., in a quorate WG Meeting in which 16 Voting Members are present, if 6 vote “yes” and 3 vote “no”, the motion passes.

g) “Member” (of a WG) is an Entitled Person who subscribes to the WG eGroup list, and is permitted to attend WG meetings. They are allowed to post messages to the WG eGroup list, to speak in WG meetings and to make Contributions to the WG. See section 6.4.

h) “Minimum Membership” means five Voting Members of a WG representing at least three XBRL member organisations.

i) “Observer” is an Entitled Person who subscribes to the WG eGroup list, and is permitted to attend WG meetings. They are not allowed to post messages to the WG eGroup list, or speak in WG meetings except by invitation of the chair, or make Contributions to the WG. See section 6.4.

j) “Proper Majority Vote” is a WG vote in which more than 50% (more than half) of the Voting Members vote “yes”, irrespective of the number of Voting Members present in the meeting and not counting abstentions. e.g, suppose that in a WG there are 16 Voting Members, then at least 9 Voting Members must vote “yes” in order for a motion to pass.

k) “Public” and “publicly” mean all people, whether XBRL Participants or not.

l) “Quorate WG Meeting” is a WG meeting at which a quorum is present. A meeting that is not quorate is “inquorate”.

m) “Quorum” is the number of Voting Members of a WG that must be present in a WG Meeting so that Resolutions and decisions may be made. The Quorum for XBRL International Inc. WG meetings is a majority (more than half) of Voting Members

n) “Resolution” means a decision reached by a WG or a WGSC as a result of a vote. Resolutions require a Majority Vote to pass, unless this process dictates that a Proper Majority Vote or Super-Majority Vote is necessary.

o) “Substantive Change” is a change to work product (such as a specification or a taxonomy or best-practice guidance material) that would require a conformant application or implementation to be modified or rewritten in order to remain conformant.

p) “Super-Majority Vote” is a WG vote in which at least 2/3 (two thirds) of the Voting Members vote “yes” and no more than 1/4 (one quarter) of the Voting Members vote “no”. These numbers are based on the total number of Voting Members, irrespective of the number of Voting Members present in the WG Meeting, without counting abstentions. For example, in a WG in which there are 18 Voting Members, at least 12 Voting Members must vote “yes” for a motion to pass in a Super-Majority Vote; but if 5 or more vote “no” then the motion fails. All Super-Majority Votes must be conducted by the XBRL International Inc. WG Administrator.

q) “Voting Member” is a Member of a WG who may vote in the WG. See section 6.4.

r) “WG Meeting” is a meeting of the WG that is properly called and scheduled in advance. See section 6.10.

s) “WG organiser” is an Entitled Person who performs the function of organizing the first meeting of the WG - see section 6.2.

t) “WG Subcommittee” (or “WGSC”) is a group of Members of a WG producing work product for consideration or adoption by the parent WG.

u) “WG Working Draft” is any version of work product (such as a specification or a taxonomy or best-practice guidance material) of the WG which has not yet received any level of approval from the WG.

v) “Working Group” (or “WG”) means a group of individuals composed of at least the Minimum Membership that has been formed and which is conducted according to this XBRL International Inc. WG Process.

w) “XBRL International Inc. WG Administrator” (or “WG Administrator”) is the person or persons representing XBRL International Inc. in respect of WG related administrative matters.

x) “XBRL member organisation” is a firm that is a member of a Jurisdiction, or a direct member in XBRL International.

y) “XBRL Participant” is a person who is an employee of a firm that is an XBRL member organisation or an individual, academic or other category of member of a Jurisdiction, where the appropriate Jurisdiction has such category.

6 Working Group life cycle and internal processes

To provide a framework in which WGs can function effectively the following aspects must be taken into consideration:

A Working Group (WG) has a start, a middle and an end to its existence. This is true for all WGs even those designated as “standing” WGs by the XSB although in those cases the “end” is not specifically anticipated at the start. Most WGs are wound up once they have finished producing the work product for which they were formed.

Individuals interact with WGs either as “members” or in some other capacity. Certain criteria are applied to determine the capacity in which any individual that interacts with a WG does so.

WGs need leaders – these are denoted in Figure 1 as Chair and Vice-Chair.

To conduct business and make decisions WGs communicate electronically and in person as well as holding more or less regular meetings. These must follow certain rules.

To ensure that the work product of WGs conforms to any legislation or requirements generated as a result of patent claims etc. there must be certain safeguards in place.

There are two ways in which WGs can be formed. One is at the instigation of the XSB and the other is at the instigation of a group of members. In both cases the XSB is responsible for approval of the formation of the WG. The XSB will apply criteria as it sees fit in making this determination but which shall include the consideration and assessment of a) the appropriateness of the proposed WG’s activities in the context of the XII standards setting strategy and b) the availability and commitment of resources to perform the proposed activities.

The following paragraphs describe in detail the stages in the WG lifecycle. In summary, however, they are as follows:

Formation:

If the WG is formed at the instigation of members then an eGroup (which is an electronic discussion list) is created to ascertain interest from the membership at large. From exchanges on that list a charter is prepared and submitted to the XSB for approval. If at the instigation of the XSB a charter is prepared by individuals identified by the XSB and approved by the XSB.

Conducting business:

Once the WG is chartered it conducts business using a combination of its eGroup, telephone conference calls and face to face meetings. It may create subcommittees to perform sub tasks as it sees fit. It creates work product according to the Work Product Life Cycle as defined in section 7 below. It reports regularly to the XSB so that its work can be monitored and guided within the overall strategy of XII as appropriate.

Closing:

Once the WG has completed the business for which it is chartered it prepares and publishes a final report and is closed by the XSB.

Rechartering:

At times it maybe appropriate for a WG that has completed (or partially completed) the business for which it was originally chartered to be re-chartered to conduct “follow on” business that is substantially of the same scope as that for which it was originally chartered but which is necessary to reflect changed circumstances. Such changed circumstances may include:

· new technology becoming available,

· experience being gained in actual implementation of its original work product

· identification of an expanded scope that is closely related to the original scope (although the XSB will take considerable care to ensure that this is not simply “scope creep” but is, indeed necessary – at times a new WG might be formed rather than the old one being rechartered)

The following diagram outlines the Working Group formation process which is described in more detail in subsequent sections.

Figure 2: Working Group Formation Process

6.1 WG eGroups

Any group of at least three Entitled Persons may begin an eGroup for the purpose of proposing the formation of a WG. No more than two of the minimum number of three may be employees of the same XBRL Member Organisation. To do so they must submit to the XBRL International Inc. WG Administrator the following items:

The name of the eGroup. This must not be the same as the name of the eGroup that the WG itself shall use if formed.
The names, e-mail addresses and membership affiliations of the three or more Entitled Persons proposing to create the eGroup.
The name of the eGroup leader(s).
A draft statement of scope for the WG.

Within 15 days of receiving the submission, the XBRL International Inc. WG Administrator shall provide these materials to the membership and issue a “Call For Participation” inviting members to subscribe to and participate in the eGroup.

Discussion on the eGroup is restricted to evaluating the interest in proposing a new XBRL International Inc. WG, and defining the proposal for one or more new XBRL International Inc. WGs. The list of subscribers to the eGroup shall be available to all subscribers subject to any relevant privacy legislation. The eGroup shall automatically close 90 days after the “Call For Participation” is issued.

6.2 WG Formation

Any group of at least Minimum Membership shall be authorized to request the XSB to form a WG by submitting to the XBRL International Inc. WG Administrator the following items, written in English and provided in electronic form. The proposal shall not have any additional information other than that described below.

The Charter of the WG, which includes only the following items:

The name of the WG. This name must not have been previously used for any XBRL International Inc. WG and must not include any trademarks or service marks not owned by XBRL International Inc. It is subject to WG Administrator approval and may not include any misleading or inappropriate names. It must specify any acronyms or abbreviations of the name that is intended to be used to refer to the WG.
A statement of purpose, including a definition of the problem to be solved.
The scope of the work of the WG, which must be relevant to the mission of XBRL International Inc., This must include a definition of what is and what is not the work of the WG, and how it can be determined when the work of the WG has been completed. The scope may include a specific contribution of existing work as a starting point. Other contributions may be made by Members on or after the first WG Meeting of the WG. Such other contributions must be considered by the members of the WG on an equal basis to improve any original starting point contribution.
A list of deliverables, with projected completion dates.
The expected audience or users of the work.

Additional information regarding the start up of the WG, which includes:

Identification of similar or applicable work that is being done in other XBRL International Inc. WGs or by other organisations, why there is a need for additional work in this area and how the proposed WG will be different, and what level of liaison will be sought with such other organisations. (Required)
A list of contributions of existing technical work that it is anticipated will be made to this WG. (Optional)
A proposed working title and acronym for the specification(s) or other work product to be developed by the WG. (Optional)
The date, time, and location of the first WG Meeting, whether it will be held in person or by phone. The first WG Meeting of a WG must occur within 30 days of the announcement of its formation in the case of a telephone or other electronic WG Meeting, and within 45 days after the announcement of its formation in the case of a face-to-face WG Meeting. (Required)
The projected on-going WG Meeting schedule for the year following the formation of the WG, or until the projected date of the final deliverable, whichever comes first.
The names, e-mail addresses, and membership affiliations of at least Minimum Membership who support this proposal and are committed to the Charter and projected WG Meeting schedule.
The name of the WG organiser who must be an Entitled Person.

As soon as practical following the submission the XSB will consider the request and either approve the WG formation or request modifications to be submitted within a certain timeframe or reject the request.

If approval is given the XBRL International Inc. WG Administrator will then provide these materials to the XII membership with a Call For Participation and an announcement of a first WG Meeting.
If the XSB has requested modifications the XBRL International Inc. WG Administrator will notify the submitters of the XSB decision including the details of the modifications requested, including a timeframe within which the request must be resubmitted. If the request is resubmitted within the required timeframe then the XSB shall again consider it as soon as practical following this re‑submission and shall apply this process to the revised submission.
If the XSB has rejected the request the XBRL International Inc. WG Administrator will notify the submitters of the XSB decision. If desired, the requesters may appeal the decision to the ISC by writing to the Chair of the ISC giving reason for their appeal. The ISC shall then dispose of the appeal as it sees fit. Such disposition may include confirmation of the XSB decision or providing instructions to the XSB as to how to proceed otherwise.

6.3 First WG Meeting of a WG

No less than 15 days prior to the first WG meeting of the WG, Entitled Persons who intend to participate in the first WG Meeting must register as a Member by sending an e-mail to the WG organiser, copying the XBRL International Inc. WG Administrator , and specifying whether they intend to gain voting rights.

If the Entitled Person is an employee or designee of an XBRL International Inc. member organisation, they must confirm to the XBRL International Inc. WG Administrator that they have permission of that organisation to participate in the WG and that the organisation agrees to abide by the IP policy in respect of their participation. Upon receiving such confirmation, the XBRL International Inc. WG Administrator will provide a copy thereof to the Primary Representative of that organisation as registered in the records of XBRL International Inc. or the relevant XBRL jurisdiction

Every Entitled Person who has so registered and been confirmed will be a Member of the WG effective from the date of the first WG Meeting. Every Entitled Person who has so registered, requested voting rights, been confirmed, and is present at the first WG Meeting of a WG will be a Voting Member of the WG effective from the date of the first WG Meeting. Persons who register to attend the first WG Meeting but do not attend must notify the WG Chair after the first WG Meeting to become a Member of the WG, as described in section 6.4.

The first WG Meeting of a WG must take place when, where and how it has been described in the announcement. Any first WG Meeting whose time or location is changed and any initial telephone or other electronic WG Meeting that fails to grant access to every Entitled Person previously registering to attend shall be subject to appeal to the XSB

At least Minimum Membership must become Voting Members at the first WG meeting or the WG shall be considered not to have been successfully started and shall be closed.

At the first WG Meeting the WG MUST suggest the name of a Chair and Vice-Chair to the XSB as the first order of business, from among nominations made by Voting Members at that WG Meeting. The XSB will consider the request as soon as practical thereafter and either confirm those individuals in their roles or appoint alternative individuals from among the Voting Members of the WG. Once the Chair is appointed by the XSB the role of WG organiser ends. The WG organiser acts as Chair until that appointment has been made.

6.4 WG Membership and Participation

WG membership is on an individual basis, not on a per organisation basis. WG membership may not be transferred from person to person. No individual may attend a WG meeting unless they fall into one of the following categories.

Observer

An Entitled Person may become an Observer of a WG by registering as such. To do this they must send an e-mail to the WG organiser or Chair (depending on the status of the WG at the time), copying the XBRL International Inc. WG Administrator. If the Entitled Person is an employee or designee of an XBRL International Inc. member organisation, the XBRL International Inc. WG Administrator will inform the Primary Representative of that organisation as registered in the records of XBRL International Inc. or the relevant XBRL jurisdiction that the person has requested to become an Observer. The Observer is not a Member of the WG. There are therefore no attendance or participation requirements in order to maintain this status. They must, however, remain an Entitled Person.

Member

Any time after the first WG Meeting, an Entitled Person can become a Member of an existing WG by registering as a Member. If the Entitled Person is an employee or designee of an XBRL International Inc. member organisation, they must confirm to the XBRL International Inc. WG Administrator and the WG Chair that they have permission of that organisation to participate in the WG and that the organisation agrees to abide by the IPR policy in respect of their participation. Upon receiving such confirmation, the XBRL International Inc. WG Administrator will provide a copy thereof to the Primary Representative of that organisation as registered in the records of XBRL International Inc. or the relevant XBRL jurisdiction Upon receipt by the Chair of this confirmation the Member may begin participating, but shall not have voting rights. A Member shall become eligible to vote in the WG when the requirements below are met.

Voting Member

After the first WG Meeting of a WG, a Member who has indicated their intention to obtain voting rights, and who has not obtained those rights by virtue of their attendance at the first WG Meeting, and who has not lost previously held voting rights as a result of non-attendance as detailed in the following paragraph, shall obtain such rights at the close of the second consecutive WG Meeting attended or 60 days after becoming a Member, whichever comes first.

A Voting Member must remain active in a WG to maintain voting rights. A Voting Member who is absent from three consecutive WG Meetings or six weeks which ever is the longer period of time (as recorded in the minutes) loses his or her voting rights at the end of the third consecutive WG Meeting missed or at the end of the first WG meeting missed after a six week absence, which ever is the later time. Being absent “for six weeks” means that a Voting member has not attended any meetings in a period of six calendar weeks PLUS has been absent for the first meeting AFTER the six week anniversary of the most recent meeting they have attended. Thus, by way of example, if meetings are held every two weeks, missing four consecutive meetings is the same as being absent for six weeks. If they are held every three weeks then missing three consecutive meetings is equivalent to being absent for six weeks. In any doubtful or ambiguous circumstance (such as considering the timing of the meetings during a particular day or the effect of daylight savings time etc.) the interpretation shall enure in favour of the member retaining their voting rights.

A Member who has lost his or her voting rights shall regain them by attending two consecutive WG Meetings (as recorded in the minutes), thus regaining voting rights after the end of the second WG Meeting attended. A Member of a WG that does not hold two WG Meetings within a 60 day period may regain voting rights by making a request to the chair(s) to regain them, effective 60 days after the request.

Voting Members who lose their voting rights remain Members of the WG. The Chair may send a warning to the Member, but the loss of voting rights is automatic and the sending of a warning is not a requirement.

6.5 Termination of WG Membership

Except as provided in 6.6, termination of membership in an XBRL International Inc. WG shall occur under the following conditions:

A Member is considered to have resigned from a WG upon their sending notification of resignation to the WG eGroup.
Persons who lose Entitled Person status for reasons including, but not limited to, change of employment have up to 30 calendar days of WG membership as an Individual Member in which to request a Leave of Absence or re-establish eligibility. A Member loses WG membership on the 31st day after losing Entitled Person status or at the end of a Leave of Absence requested as specified in section 6.6 if Entitled Person status has not been re-established.
The Chair may, after giving due warning, terminate the membership of any individual who behaves in an unprofessional manner. This includes but is not limited to use of abusive or foul language, spamming of the mailing list, harassment of other members etc. Any such individual whose membership is so terminated may appeal against the termination to the XSB.

Termination of membership in an XBRL International Inc. WG shall automatically end voting rights in the WG as well as membership in any WG Subcommittee of that WG.

6.6 Leaves of Absence

Every Voting Member of an XBRL International Inc. WG is allowed at least one Leave of Absence during any one twelve month period. During a Leave of Absence, a Voting Member is exempt from the participation criteria specified in section 6.4. A first Leave of Absence during any one twelve month period is granted automatically upon application to the Chair of the WG. The Chair must notify the WG of any Leave of Absence by reporting it in the minutes of the first WG Meeting following the granting of that Leave of Absence.

A Voting Member who has already taken a Leave of Absence during any twelve month period may apply for a maximum of one additional Leave of Absence during the same twelve month period, but a second Leave of Absence during any twelve month period can be granted only upon formal Resolution of the WG.

A Voting Member of a WG who has been granted a Leave of Absence shall not have voting rights in the WG or any of its WG Subcommittees for the duration of the Leave; voting rights shall resume immediately upon the person returning from Leave.

The length of a Leave of Absence shall be specified in advance by the Voting Member requesting it and shall not exceed 60 days. A Leave of Absence shall begin no earlier than seven days after the date upon which the request was submitted to the Chair of the WG and shall end on the date specified, or at the beginning of the first WG meeting or WG Subcommittee WG Meeting attended after the Leave begins, or upon transmittal of the first mail ballot returned after the Leave begins, whichever comes first. Time allocated for a Leave of Absence but not used due to early resumption of participation cannot be carried over into another Leave.

6.7 WG Chairs and Vice-Chairs

Each WG must have a Chair and a Vice-Chair. Only Voting Members of the WG are eligible to be Chair, Vice-Chair or co-Chair. The initial WG Chair and Vice-Chair are appointed by the XSB as defined in section 6.3. If the WG does not have a Chair and does not have a Vice-Chair then all WG activities, with the exception of the selection of a new Chair and/or Vice-Chair, are suspended.

The responsibilities of Chair of a WG may be discharged by no more than two co-Chairs at the discretion of the XSB (although having co-Chairs is only to be implemented in unusual circumstances as it is not considered a desirable way of organising WGs – having a Vice-Chair fill the role of Chair in the absence of the Chair is preferred). In the event that the Chair position is so shared each co-Chair is equally responsible for the Chair duties and responsibilities. Throughout this WG Process, whenever a notification to the WG Chair is required this must be made to both co-Chairs.

A WG Chair or Vice-Chair may be removed by the XSB or by a Super-Majority Vote of the WG. In the event that a WG has co-Chairs each may be removed individually or both may be removed by a single action.

A vacancy in chairing a WG shall be deemed to exist when (i) the Chair or one or both co-Chairs has been removed, (ii) the Chair or one or both co-Chairs has resigned the position, or (iii) the Chair or one or both co-Chairs ceases to be a member of the WG. Vacancies in chairing a WG shall be filled by the XSB from the membership of the WG.

The same provisions regarding Leaves of Absence shall apply to the Chair or co-Chair of a WG as to the other members of a WG, except the Chair must notify both the XBRL International Inc. WG Administrator and the WG at least 30 days prior to any non-emergency leave of absence. In the event of the Chair being on Leave of Absence the duties of the Chair are to be carried out by the Vice-Chair.

The Vice-Chair carries out all the duties of the Chair in the Chair’s absence. Where a WG is expected to continue its work for a period of more than 12 months the WG should consider annually any changes to the Chair or Vice-Chair and advise the XSB of its recommendation. The XSB will then determine what, if any, changes are to be made.

6.8 WG Visibility

The official copies of all resources of the WG and its associated WG Subcommittees (WGSCs), including web pages, documents, eGroup lists and any other records of discussions, must be located only on facilities designated by XBRL International Inc. WGs and WGSCs MUST NOT conduct official business or technical discussions, store documents, or host web pages on servers or systems not designated by XBRL International Inc. In the event of WG members hosting non-XBRL International websites pertaining to the subject matter being addressed by the WG they must indicate clearly that the site is not an official XBRL International WG website and they must also ensure that no work product of the WG that has not been authorised for publication is displayed on that website. All web pages, documents, ballot results and eGroup archives of all WGs and WGSCs shall be available to all XII members upon request to the XBRL International Inc. WG Administrator.

eGroups

Upon formation each WG will be provided with a general discussion eGroup list and a means to collect public comments. Subscription to the general eGroup list shall be required for Members, Voting Members, and Observers of the WG.

The minutes of each WG meeting and a record of all decisions must be published to that WG’s general eGroup list on a timely basis, and at least 2 working days before the next meeting. All official communications and non-verbal discussions of the WG must take place on the eGroup list. All WG eGroup lists shall be archived for the duration of the consortium, and all WG eGroup archives shall be available to all XII members upon request to the XBRL International Inc. WG Administrator.

The reason for a WG having a public comment facility is to facilitate receiving comments from the public and is not for public discussion. Comments shall be publicly archived, and shall be forwarded to one or more Members of the WG including the WG Chair. WGs are not required to respond to comments. Comments to the WG made by Members of the WG must be submitted via the WG general eGroup list, and comments made by non-WG members, including from the public, must be made via the WG’s comment facility. Comments shall not be accepted in any other way

Collaborative Workspace

The XBRL International Inc. WG Administrator shall provide the WG with an online workspace for collaboration, file storage, calendaring functions etc. The WG must keep the following information current in the WG collaborative workspace: the WG name and Charter; standing rules and other adopted procedures; WG Meeting schedule; anticipated deliverables and delivery dates; list of Members and Observers, identifying those with voting privileges; the name and e-mail address of the WG Chair or co-Chairs and Vice-Chair as well as any other important positions that may have been created by the WG; list of WG Subcommittees, their deliverables, and members; draft and completed WG documents with identification of the most recent versions of the WG’s work product; and copies of the IPR declarations for that WG.

Announcements

The XBRL International Inc. WG Administrator shall create an archived list for announcements from the XBRL International Inc. WG Administrator regarding WGs. Any Entitled Person shall be eligible to subscribe to this list. Every important change in WG status will be posted to the announcement list; such changes including but not limited to the following: WG formation; WG Charter revision; announcements of any change in the status of WG work product as it passes through the Work Product Life Cycle; and closure of a WG.

6.9 WG Procedure

The operation of WGs shall be governed by Robert’s Rules of Order Newly Revised, insofar as such rules are not inconsistent with or in conflict with this WG Process, the XBRL International Inc. IP Policy, the XBRL International Inc. Bylaws, other XSB-approved policies, or with provisions of law. The duration of a WG shall be considered a single session. The official language of all WGs shall be English with all written material being in UK English. Members of WGs who wish to communicate with each other on WG business in other languages may do so between themselves provided that they provide an English language translation of their communication for the benefit of other WG members and other XBRL Participants.

Standing rules may be adopted by Proper Majority Vote of the WG. The WG may not adopt standing rules or other Resolutions related to Intellectual Property Policy, quorum requirements, membership, voting, participation, or that otherwise conflict with or supersede any XBRL International Inc. policy. Standing rules must be communicated to the XSB, who may override them if they conflict with XBRL International Inc. policy. They must also be published in the WG’s collaboration tool.

6.10 WG Meetings

WG meetings must be scheduled in advance and properly called by publishing an announcement of the date, time and place (or phone number) of the meeting to the WG’s eGroup. WG Meetings scheduled or conducted so as to exclude any Member are subject to appeal to the XSB. WG Meetings may be conducted face-to-face or via telephone conference or other electronic media that allow participation of all Members of the WG. Meeting minutes must be recorded and published to the WG’s eGroup and archived in the WG’s collaboration tool.

If a meeting is inquorate discussions may take place but no business leading to a vote may be conducted; those present may act as a “Committee of the Whole” as defined in Robert’s Rules of Order Newly Revised, and make a report to the entire WG. Attendance must be recorded in the WG Meeting minutes. Inquorate WG Meetings shall nevertheless count towards attendance for purposes of Members gaining, maintaining, or losing voting rights.

6.11 WG Charter Clarification

A WG may clarify its Charter only to remove ambiguity or to narrow the scope of the topic defined by the Charter. The WG may not broaden or otherwise change its scope of the topic of work without XSB approval. This is not considered “Clarification” but is “Rechartering” which is covered by section 6.12 below. The list of deliverables may be expanded only if the new deliverables are within the scope of the topic.

Approval for clarification shall require a Super-Majority Vote of the WG. The clarification of the Charter may occur no earlier than the first WG Meeting of the WG. The WG Chair shall notify the XBRL International Inc. WG Administrator that a motion has been made to clarify the Charter, and the WG Administrator shall set up and conduct the ballot.

The XBRL International Inc. WG Administrator may prevent the proposed clarification from coming to vote if it is not in conformance with XBRL International Inc. policies. The XBRL International Inc. WG Administrator must within 15 days either open the ballot or reply to the WG with the reason why the change cannot be voted upon. In the event of the latter circumstance pertaining the mover of the motion to be voted on may appeal the XBRL International Inc. WG Administrator’s decision to the XSB. The clarified Charter shall not take effect until approved by the XSB and announced by the XBRL International Inc. WG Administrator. The XBRL International Inc. WG Administrator shall publicise approved changes in the same manner as the initial formation of the WG is publicised.

6.12 WG Rechartering

A WG may be rechartered for purposes of expanding the scope of the WG. The WG shall retain the name of the predecessor, and all eGroups and archives, collaboration tools, etc. shall be transferred from the predecessor WG to the rechartered WG. However, any Contributions made to the previous WG must be recontributed.

A proposal to recharter the WG must be submitted to the XBRL International Inc. WG Administrator. This proposal shall be in all respects the same as a proposal to form a new WG with the exception that the WG name must be the same as the predecessor WG. The XBRL International Inc. WG Administrator shall reply to the proposers within 15 days, and if the proposal is complete shall schedule a ballot. Approval for rechartering shall require a Super-Majority Vote of the WG being rechartered and ratification by the XSB. Upon approval of the ballot and ratification by the XSB, the XBRL International Inc. WG Administrator shall announce the newly rechartered WG in the same manner as a new WG. Membership in the rechartered WG shall be determined in the same manner as for a new WG. The predecessor WG shall be closed at the end of the day prior to the date of the first WG Meeting of the rechartered WG. The time period for determining Members’ Participation Obligation shall restart at the first WG Meeting of the new WG.

6.13 WG Voting

WG votes require a Majority Vote to pass, except as noted elsewhere in this Process. All WG ballots requiring a Super-Majority Vote for approval must be conducted by the XBRL International Inc. WG Administrator. The WG Chair must notify the XBRL International Inc. WG Administrator that a motion has been made that requires a Super-Majority Vote, and the XBRL International Inc. WG Administrator will set up and conduct the ballot.

Eligibility

A Member of a WG must have voting rights to make or second a motion, and must have voting rights at the time a ballot is opened in order to vote on that ballot. Every Voting Member of a WG has a single vote. Organisations do not vote in WGs. Proxies are not allowed in WG voting.

Electronic Voting

WGs may conduct electronic ballots, either by using the WG’s general eGroup list or any other electronic voting functionality provided by XBRL International Inc. The minimum period allowed for electronic voting shall be seven calendar days; the WG may specify a longer voting period for a particular electronic ballot.

A motion to open an electronic ballot must be made in a WG meeting unless the WG has adopted a standing rule to allow this motion to be made on the WG’s eGroup. If such a rule has been adopted, motions made on the eGroup must also be seconded and discussed on that list.

6.14 WG Subcommittees

The WG may by Resolution create a WG Subcommittee (WGSC). The Resolution must be minuted, and must include the name, statement of purpose, list of deliverables, and name of the Chair of the WGSC. All of these items must fall within the Charter of the WG and conform to XBRL International Inc. policy.

The deliverables of the WGSC are made only to the WG. Members of the WGSC must first be Members of the WG. Observers of a WG may be Observers of a WGSC, but may not become WGSC members without first becoming a Member of the WG. A WGSC member may resign from the WGSC and remain a Member of the WG.

6.15 Closing a WG

A WG may be closed by Proper Majority Vote of the WG, by Resolution of the XSB, or by the XBRL International Inc. WG Administrator.

The XBRL International Inc. WG Administrator must close a WG that has completed the deliverables listed in its Charter if the WG does not add new deliverables.

The XBRL International Inc. WG Administrator may close a WG that fails to conduct at least one Quorate WG Meeting during any six month period; whose membership falls below the Minimum Membership; which has not completed its deliverables within the schedule listed in its Charter; or which has failed to show progress towards achieving its purpose as defined by its Charter.

6.16 Intellectual Property Rights Procedures

The WG shall operate in accordance with the XBRL International Inc. Intellectual Property (IP) Policy.

Notices of Disclosed Claims, as defined in and required by the XBRL International Inc. Intellectual Property (IP) Policy, shall be made by sending an email message to the XBRL International Inc. WG Administrator, who shall post the disclosure in the WG’s collaboration tool and notify the WG via the WG eGroup. The WG shall make no formal decision with regard to the applicability or validity of an IP disclosure.

Contributions, as defined in the XBRL International Inc. Intellectual Property (IP) Policy, shall be made by sending to the WG’s eGroup either the contribution, or a notice that the contribution has been submitted to the WG’s document repository; a URL or other reference is not adequate. Written contributions must be converted to electronic format and submitted to the WG’s eGroup or collaboration tool. The WG is not required to acknowledge or use any Contribution.

Additionally a call for claims MUST be made at the start of every WG meeting by the chair putting the following question to the meeting:

“This is a call for any claims under any patent applications or issued patents that would be likely to be infringed by an implementation of the specification or other work product which is the subject of this meeting, as per XBRL International Intellectual Property Policy (XIIIPP). Are there any such claims?”.

Adequate time shall be provided for any such claims to be heard and the chair may decide to repeat the question if they feel it is appropriate or necessary. The calling of this question, and its wording, must appear in the published agenda for every WG meeting.

Every published agenda for WG meetings shall also contain the following text:

“This WG Meeting is open to XBRL Participants and individuals who have been deemed by ISC or the XSB to be entitled to the same privileges as an XBRL Participant in respect of WG Meeting attendance only. WG Meeting attendees are bound by the XBRL International Intellectual Property Policy (XIIIPP). If you do not agree to the policy, or do not understand its implications, you MUST NOT attend the meeting. In particular, you should be aware of the content of Section 11 as follows:

“Each Member represents, warrants, and covenants that it will not submit any Contribution that may subject any Contribution or Recommendation, in whole or in part, to licensing obligations with additional restrictions or requirements inconsistent with those set forth in this IP Policy, or that would require any portion of such Contribution to be: (i) disclosed or distributed in source code form; (ii) licensed for the purpose of making derivative works; or (iii) redistributable at no charge. If a Member or Participant has knowledge that a Contribution has been made that may subject any Contribution or Recommendation, in whole or in part, to one or more of the licensing obligations listed in this section 11 above, such Member or Participant will give prompt notice of the same to the Working Group Chair.”

6.17 Specification Quality

All documents and other files produced by the WG, including specifications at any level of approval, must use the XBRL International Inc. file naming scheme, and must include the XBRL International Inc. copyright notice. All document files must also use the XBRL International Inc. document templates. The name of any specification may not include any trademarks or service marks not owned by XBRL International Inc.

The specification MUST include a list of people who participated in the development of the specification. This list shall be initially compiled by the Chair, and any Member of the WG may add or remove their names from the list by request. The final list shall be approved by the Chair and Vice-Chair taking into account the contribution made by each individual. Criteria such as “providing deliverables or drafts of deliverables in a timely fashion”, “being familiar with the relevant documents of the Working Group, including minutes of past meetings”, “following discussions on relevant mailing list(s)” are to be applied in making this evaluation. If a person’s name is omitted following this evaluation and they object to its omission they have the right of appeal to the XSB.

Editable formats of all versions of WG documents must be stored in the WG’s collaborative workspace. The XSB MAY set specific standards for the format of such documents from time to time.

All schema and XML instances, whether by inclusion or by reference, including fragments of such, must be well formed. All expressions must be valid. All machine-processable schemas, XML instances etc. that are part of the specification must be available separately in their own plain text file with their own file name. There shall be only one normative version of any such artefact and non-normative copies provided for “ease of processing” or other purposes shall be identified as non-normative appropriately.

A specification, taxonomy or document (work product) may be composed of any number of files of different types, though any such multi-part work product must have a single name and version number. Irrespective of the number and status of the constituent parts, the work product as a whole must be approved by a single WG ballot. Any change made requires a new version or revision number or indication of the errata correction status. Exceptions are for changes made to the title page and in the running footer noting the approval status and date, which are to be made after the approval of the work product.

6.18 Application to Existing WGs

This WG Process applies to previously established WGs upon its adoption. Transitional arrangements will be managed by the XSB and issues or inconsistencies dealt with on a case by case basis.

7 XII Technical Work Product Development Process

The XII Technical Work Product development process is the set of steps and requirements followed by XII Working Groups in the production of the work product for which they have been chartered. This is modelled substantially on the World Wide Web Consortium Process Document since the process described therein is very similar to that already in place in XII. Some of the issues that have arisen in following the XII processes have been encountered and addressed by the W3C and some require a “made in XII” approach.

The processes followed by a Working Group to manage specifications, guidelines and taxonomies, called technical work products in this section, include:

Advancing a technical work product from early draft to mature deliverable (“Recommendation”); this is called the XII Recommendation Path;
Ending work on a technical work product before it reaches Recommendation, or when not intended to become a Recommendation;
Modifying an XII Recommendation;
Rescinding a Recommendation no longer endorsed by XII.

The XII Technical Work Product development process is designed to maximize consensus about the content of a technical work product, to ensure high technical and editorial quality, to promote consistency among specifications, and to obtain endorsement from within XII and from the broader community.

The following sections describe:

typical components of an XII Technical Work Product
the maturity level of a Technical Work Product at each step (e.g., “Working Draft” or “Candidate Recommendation”). Note that there is not a one-to-one correspondence between steps of the Technical Work Product development process and maturity levels.
the steps of the Technical Work Product development process (e.g., “Announcement of Last Call” or “Call for Implementations”), and
the requirements for each step

The typical components of a Technical Work Product are described first followed by maturity levels, the steps of the Technical Work Product development process and the requirements for each step.

7.1 Technical Work Product

In order to ensure that Technical Work Product is not produced without regard to the market and business needs that it is supposed to address, the requirements for the finished product MUST be articulated. Requirements typically address two main aspects – the business needs and the functional needs of the work product. In the software development world there is also often an additional set of requirements articulated – the “Market Requirements”. In the XII development process these are addressed by virtue of the work done in order to initially charter a Working Group as defined in section 6.2 WG Formation. Accordingly they do not, of themselves, form part of the Technical Work Product. However, it is normal that some material from the “Market Requirements” is germane in describing the business needs and so would be incorporated into a “Requirements” document that does form part of the Technical Work Product.

The typical components of a Technical Work Product that is produced by a Working Group are therefore:

Requirements (mandatory [4])

Covers business and functional requirements, including Use Case definitions. This document is used as a cross reference to ensure that the technical work product is consistent and is what is necessary to satisfy the needs of all stakeholders.

Specification (or Taxonomy etc.) (mandatory, normative [5])

The normative document that software developers and XBRL users refer to in order to obtain an unambiguous definition of the standard.

Conformance suite (optional [6], may be normative or not)

A set of test cases (with accompanying descriptive material) that users (software vendors, taxonomy developers and/or end users) can exercise to determine their conformance to the specification with a view to ensuring interoperability.

Reference Implementation (optional, usually not normative)

Software that implements the technical work product which software vendors may use to evaluate their own offerings against. This is not intended to be competitive with software vendors’ offerings and so should have a minimal user interface, no performance optimisation and no additional “features” other than those required to produce output as defined by the specification from any input that it is given. It may be limited in various ways, for example it may implement only part of the specification or it may produce correct output only from valid input.

Basic reference on uses of the work product (optional, usually not normative)
Working Group Note(s) (optional)

Clarifying or other material produced by the WG to assist users of the Technical Work Product in effectively exercising it.

Errata Corrections (mandatory)

Once the Technical Work Product has reached REC (see 7.2.2) it is likely that errors (errata – singular erratum) will be discovered that need to be corrected. If it is decided that these are of sufficient importance to be publicly corrected they will be published by the WG subject to the processes described in 7.7.1 Errata Management. This may either be managed by the WG responsible for the Technical Work Product in the first place or, if that WG has been wound up, by a “Maintenance” WG that has that specific mandate.

Final Working Group Note (mandatory)

A final statement of the WG when it is wound up

The first two components typically will be taken together as being the main Technical Work Product of the WG, reaching REC maturity level simultaneously in that they jointly form the XII Recommendation. However separate documents that are prepared as part of the work of the WG may be published at different times although it is expected that Requirements and Specification should always move between maturity levels simultaneously as a complete “package”.

Conformance Suite, Reference Implementation and Working Group Notes may be at a different maturity level than Requirements and Specification at any time. Another example is that a Conformance Suite might never reach REC since it is the nature of test suites that real world experience continuously uncovers new situations for which new, hitherto unanticipated, tests are necessary.

7.2 Maturity Levels

The maturity level of a published Technical Work Product indicates where it is in the development process. The maturity levels “Working Draft” and “Working Group Note” are the possible initial states of a Technical Work Product in the development process. The maturity levels “Recommendation,” “Working Group Note,” and “Rescinded Recommendation” are the possible end states.

7.2.1 Maturity Level for Work in Progress

Working Draft (WD)

A Working Draft is a document that XII has published for review. There are different levels of WD depending on the breadth of the community to which it is distributed. These levels are:

Working Group WD (WGWD)

A WGWD is a working document that is under discussion by the relevant Working Group. While it is available to any XBRL Participant who wishes to see it, it is not generally published beyond the mailing lists and files areas belonging to the relevant Working Group (although if the WG decides to distribute copies to certain individuals or other WGs, possibly to obtain review and comment on specific parts of the document they may do so). A WGWD is created, edited and distributed by one (or more) of the editors of the document, to the members of the WG.

Internal WD (IWD)

An IWD is a working document that a Working Group has decided to distribute broadly to XBRL Participants, but not to the general public. This may be for the purposes of obtaining feedback commentary from the general XII membership or to provide an “early look” at a document that is planned to be distributed to the general public as a PWD or one of the later maturity level documents. In the case of later maturity levels it is identified as an “IWD of the appropriate level”, such as an “IWD of a CR” (“Internal Working Draft of a Candidate Recommendation”) for example.

Public WD (PWD)

A PWD is a working document that a Working Group has decided to distribute the general public (for the purposes of obtaining feedback commentary) and which has been approved for such publication by the XSB.

During the preparation of IWDs and PWDs there is inevitably a time when the document that is to be distributed has been prepared but distribution has not yet been approved by the responsible authority (e.g. by vote of the relevant WG or the XSB). Any document in this state is identified as such by prefixing its description with the word “Draft”.

7.2.2 Maturity Levels of the Recommendation Path

In addition to Working Drafts that are meant to proceed to Recommendation, the other maturity levels of the Recommendation Path are:

Candidate Recommendation (CR)

A Candidate Recommendation is a document that XII believes has been widely reviewed and satisfies the Working Group’s technical requirements. XII publishes a Candidate Recommendation to gather implementation experience.

Proposed Recommendation (PR)

A Proposed Recommendation is a mature Technical Work Product that, after wide review for technical soundness and implementability, the owning WG has sent to the XSB and the ISC for final endorsement and publication as an XII Recommendation.

XII Recommendation (REC)

A XII Recommendation is a specification or taxonomy or set of guidelines that, following extensive consensus-building, has received the endorsement of XII Members as represented by the XSB and the ISC. XII recommends general deployment of its Recommendations.

During the preparation of CRs, PRs and RECs there is inevitably a time when the document that is to be distributed has been prepared but distribution has not yet been approved by the responsible authority (e.g. by vote of the XSB). Any document in this state is clearly identified as such by prefixing its description with the word “Draft”, for example “Draft Candidate Recommendation” (DCR). Note that the “Proposed Recommendation” document type obviates the need for any “Draft Recommendation”.

7.2.3 Maturity Level for other publications about a Technical Work Product

Working Group Note

A Working Group Note is published by a chartered Working Group to provide additional information about its work product that is not necessarily appropriate to include in the Recommendation itself. Examples of this are: clarifying information about the interpretation of a part of a specification, guidance to implementers on interoperability issues etc. When a Working Group publishes a Working Group Note it MAY do so with or without its prior publication as a Working Draft. A Working Group Note MUST be approved by the XSB prior to publication.

7.2.4 Maturity Level When Ending Work on a Technical Work Product

Final Working Group Note

A Final Working Group Note is published by a chartered Working Group to indicate that its work has ended. When a Working Group publishes a Final Working Group Note it MAY do so with or without its prior publication as a Working Draft. A Final Working Group Note MUST be approved by the XSB prior to publication.

7.2.5 Maturity Level When Editing a Recommendation

Proposed Edited Recommendation

A Proposed Edited Recommendation is a Recommendation published for review of changes, some of which may affect conformance. When there is consensus about the changes, the document is published as a Recommendation. A Proposed Edited Recommendation MUST be approved by the XSB prior to publication.

7.2.6 Maturity Levels When Rescinding a Recommendation

Rescinded Recommendation

A Rescinded Recommendation is an entire Recommendation that XII no longer endorses.

7.3 General Requirements for Promotion on the Recommendation Path

The following diagram outlines the progress of a document through the various maturity levels on the Recommendation path. The details are described more fully in subsequent sections.

Figure 3: Progress on the Recommendation Path

In preparation for promotion to Candidate Recommendation or subsequent maturity levels up to and including publication as a Recommendation, a WG MUST:

By a Proper Majority Vote, pass a motion that requests the XSB to approve the promotion of the Technical Work Product.
Provide public documentation of all changes (both substantive and minor) to the Technical Work Product since the previous step. A substantive change (whether deletion, inclusion, or other modification) is one where it could reasonably be expected that making the change would invalidate an individual’s review or implementation experience. Other changes (e.g., clarifications, bug fixes, editorial repairs, and minor error corrections) are minor changes.
Report which, if any, of the WG’s requirements for this document have changed since the previous step.
Report any changes in dependencies with other WGs.
Show evidence of wide review and stakeholder support.
Formally address all issues raised about the document since the previous step.
Report any Formal Objections.

The following information is important to justify the decision to promote a Technical Work Product and therefore MUST be publicly available:

Documentation of all changes to the Technical Work Product (e.g., by providing “diffs” in addition to summaries of substantive changes);
A statement that all requirements have been fulfilled or a listing of unfulfilled requirements and the rationale for promoting the Technical Work Product, even though some requirements have not been met.
Evidence of wide review and that dependencies with other WGs have been resolved;
All responses that formally address issues raised by reviewers;
All Formal Objections.

7.4 Reviews and Review Responsibilities

It is known that the following actions can help to build consensus around technical work products:

Frequent publication (a guide is at least one publication once every three months or other such minimum period as determined from time to time by the XSB). However too frequent publication is undesirable. Common sense should prevail in determining the most appropriate frequency.
Early review, to find errors quickly and decrease the chances of diverging technologies.
Wide review and stakeholder support, including from other groups inside and outside of XII.

A document receives review starting with its first publication. Starting with the First Public Working Draft until the start of a Last Call review, a WG SHOULD formally address any substantive review comment about a Technical Work Product and SHOULD do so in a timely manner.

Starting with a Last Call review up to the promotion to Proposed Recommendation, a Working Group MUST formally address any substantive review comment about a Technical Work Product and SHOULD do so in a timely manner. When a Working Group requests to promote its work product to Candidate Recommendation or beyond, it MUST provide positive documentation that issues have been formally addressed (e.g., in an issues list that shows how they have been addressed).

The Director of Standards Development MUST formally address any substantive issue raised by XSB members during Proposed Recommendation, Proposed Edited Recommendation, and Proposed Rescinded Recommendation review periods. The Working Group MUST communicate to the Director of Standards Development any substantive issues raised during Proposed Recommendation, Proposed Edited Recommendation, and Proposed Rescinded Recommendation review periods by anyone other than XSB representatives.

Reviewers SHOULD NOT send substantive technical reviews late on the Recommendation Path. Reviewers SHOULD NOT expect that a Working Group will readily make substantive changes to a mature document. The more evidence a Working Group can show of wide review and stakeholder support, the less weight substantive comments will carry when provided late on the Recommendation Path. Worthwhile ideas SHOULD BE recorded even when not incorporated into a mature document.

The Working Group MUST be able to show evidence of having attempted to respond to and satisfy reviewers. Reviewers MAY register a Formal Objection any time they are dissatisfied with how a Working Group has handled an issue.

There are two formal review periods with fixed durations when promoting to Recommendation: after a Last Call announcement and after a Call for Review of a Proposed Recommendation. Out of consideration for the WG, reviewers SHOULD send their comments early in a review period. A WG SHOULD NOT start a new review before the scheduled end of an ongoing review (e.g., do not start a new Last Call review before the scheduled end of an ongoing Last Call review).

Normally, reviewers SHOULD NOT raise substantive technical issues about a Technical Work Product after the end of a Last Call review period. However, this could occur and a Working Group’s obligation to address those issues formally extends until the start of a Proposed Recommendation review period. However, to allow the WG to make progress on a technical work product, the WG MAY refuse to make substantive changes in order to address issues raised between the end of a Last Call review period and publication of a Recommendation. A reviewer MAY register a Formal Objection.

The XSB SHOULD NOT (but MAY) raise new substantive technical issues during a Proposed Recommendation review period. The Director of Standards Development MAY respond to the reviewer after the close of the Proposed Recommendation review period.

During review, the WG SHOULD also formally address informed and relevant issues raised outside the XSB (e.g., by the public or another XII Working Group), and report them to the Director of Standards Development in a timely fashion.

When a Working Group receives a substantive issue after the end of the Proposed Recommendation review period, the WG MUST respond to the reviewer but MAY decline to formally address the issue. In this case, the WG MAY consider the issue as part of tracking errata.

7.5 Promoting a Technical Work Product to Recommendation

The following are key stages reached when promoting a Technical Work Product to Recommendation.

Publication of the First Public Working Draft.
Last Call announcement
Call for Implementations. Note: The XSB MAY permit the Working Group to skip this step if the entrance criteria for the next step have already been satisfied.
Call for Review of a Proposed Recommendation.
Publication as a Recommendation.

Figure 4: Key stages on the path to Recommendation

In general, WGs embark on this process with the intent of publishing one or more Recommendations. However, the XSB MAY end work on a technical work product at any time, or MAY require a Working Group to conduct further work, possibly repeating one or more steps.

Between publication of the First Public Working Draft and Last Call announcement, a WG publishes revisions that generally include substantive changes. Between any two steps after a Last Call announcement, the WG MAY publish new drafts of the Technical Work Product at the same maturity level provided there are no substantive changes since the earlier step. If there are substantive changes the process MUST return to the Public Working Draft stage.

The XSB MUST notify the ISC and other XII groups of a revision to a Candidate Recommendation or Proposed Recommendation. It MUST notify other XII WGs and the public of a revision to a Public Working Draft and MAY notify the ISC of such a revision.

7.5.1 First Public Working Draft

Document maturity level: Working Draft.

Announcement: The Director of Standards Development MUST announce the first Working Draft publication (and all published revisions) to all XBRL Participants and to the public.

Rationale: The publication of the First Public Working Draft is a signal to the world at large to begin reviewing the document.

Entrance criteria: By a Majority Vote the WG MUST pass a motion that requests the XSB to approve the promotion of the Technical Work Product. The WG MUST obtain approval of the XSB to publish the first Public Working Draft and any other Public Working Drafts.

Ongoing work: After publication of the First Public Working Draft, the Working Group normally revises the Technical Work Product in accordance with its charter.

In order to make Working Drafts available to a wide audience early in their development, the requirements for publication of a Working Draft are limited to an agreement by a chartered Working Group to publish the Technical Work Product. This MUST be ratified by the XSB prior to publication. Consensus is not a prerequisite for approval to publish; the Working Group MAY request publication of a Working Draft even if it is unstable and does not meet all Working Group requirements.

Working Groups SHOULD encourage early and wide review of the technical work product, within and outside of XII, especially from other Working Groups with dependencies on the technical work product. ISC representatives SHOULD encourage review within their jurisdictions and member organizations as early as First Public Working Draft, i.e., before a Last Call announcement and well before a Call for Review of a Proposed Recommendation.

The Working Group SHOULD be responsive to and facilitate ongoing review by addressing issues in a timely manner and clearly indicating changes between drafts (e.g., by providing “diffs” and summaries of substantive changes).

Possible next steps:

Forward: Last Call announcement, generally done after a series of Working Drafts.
Otherwise: end work

7.5.2 Last Call Announcement

Document maturity level: Working Draft.

Announcement: The Director of Standards Development MUST announce the Last Call to other XII WGs and to the public. A Last Call announcement MUST:

specify the deadline for review comments;
identify known dependencies and solicit review from all dependent WGs;
solicit public review including identifying of significant stakeholders and engaging in communication intended to obtain feedback specifically with them.

Rationale: A WG’s Last Call announcement is a signal that:

the WG believes that it has satisfied its relevant technical requirements (e.g., of the charter or requirements document) in the Working Draft;
the WG believes that it has satisfied significant dependencies with other work;
other WGs SHOULD review the document to confirm that these dependencies have been satisfied.

In general, a Last Call announcement is also a signal that the WG is planning to promote the Technical Work Product to later maturity levels.

A Working Group SHOULD work with other interested and relevant WGs prior to a Last Call announcement to reduce the risk of surprise during this stage.

It is hoped that, after a Last Call announcement, a WG will receive only indications of support for the document, with no proposals for substantive change. In practice, Last Call announcements could generate comments that sometimes result in substantive changes to a document. A WG SHOULD NOT assume that it has completed its work when it issues a Last Call announcement.

Entrance criteria: Before announcing a Last Call, the WG MUST:

By a Majority Vote, pass a motion that requests the XSB to approve the promotion of the Technical Work Product.
Fulfil the relevant requirements of the WG charter and those of any accompanying requirements documents, or report which relevant requirements have not been fulfilled.
Indicate which dependencies with other work the WG believes it has satisfied, and report which dependencies have not been satisfied.
Obtain approval of the XSB to issue the Last Call

Duration of the review: The announcement begins a review period that SHOULD last at least three weeks but MAY last longer if the Technical Work Product is complex or has significant external dependencies.

Ongoing work: During the review period, the Working Group solicits and responds to comments from XII participants, other WGs and the public.

In order to ensure the proper integration of a Technical Work Product in the international community, starting at this step in the Recommendation process, the Technical Work Product SHOULD include a statement about how the technology relates to existing international standards and to related work outside of XII.

Possible next steps:

Forward: Call for Implementations or Call for Review of a Proposed Recommendation
Otherwise: return to Working Group or end work

7.5.3 Call for Implementations

Document maturity level: Candidate Recommendation.

Announcement: The Director of Standards Development MUST announce the Call for Implementations to the ISC and to the Public

Rationale: At this step, XII believes the Technical Work Product is stable and appropriate for implementation. The Technical Work Product MAY still change based on implementation experience.

Entrance criteria: The Director of Standards Development calls for implementation when satisfied that the Working Group has fulfilled the General Requirements for Promotion on the Recommendation Path.

The WG is NOT REQUIRED to show that a Technical Work Product has two independent and interoperable implementations as part of a request to the Director of Standards Development to announce a Call for Implementations. However, the WG SHOULD include a report of present and expected implementations as part of the request.

In the Call for Implementations, the WG MAY identify specific features of the Technical Work Product as being “features at risk.” General statements such as “We plan to remove any unimplemented feature” are not acceptable; the Working Group MUST precisely identify any features at risk. Thus, in response to a Call for Implementations, reviewers can indicate whether they would register a Formal Objection to the decision to remove the identified features.

After gathering implementation experience, the WG MAY remove features from the Technical Work Product that were identified as being “at risk” and request that the Director of Standards Development issue a Call for Review of a Proposed Recommendation. If the Working Group makes other substantive changes to the technical work product, the Director of Standards Development MUST return it to the Working Group for further work.

The request to the Director of Standards Development to advance a Technical Work Product to Candidate Recommendation MUST indicate whether the Working Group expects to satisfy any Proposed Recommendation entrance criteria beyond the default requirements (described below).

Permission of the XSB MUST be obtained to issue the Call for Implementations.

Duration of the “Call for Implementations” period: The announcement MUST indicate a minimal duration, before which the Working Group MUST NOT request a Call for Review of a Proposed Recommendation; this minimal duration is intended to allow time for comment. The announcement SHOULD also include the WG’s estimate of the time expected to gather sufficient implementation data.

Possible next steps:

Forward: Call for Review of a Proposed Recommendation
Otherwise: return to Working Group or end work

7.5.4 Call for Review of a Proposed Recommendation

Document maturity level: Proposed Recommendation.

Announcement: The Director of Standards Development MUST announce the Call for Review to the XSB.

Rationale: At this step, XII seeks endorsement of the stable technical work product. The outcome of this review is taken as an indication of XII’s support for the technical work product.

Entrance criteria: The Director of Standards Development calls for review when satisfied that the Working Group has:

Fulfilled the General Requirements for Promotion on the Recommendation Path;
Shown that each feature of the Technical Work Product has been implemented. Preferably, the WG SHOULD be able to demonstrate two interoperable implementations of each feature. If the Director of Standards Development believes that immediate XSB review is critical to the success of a technical work product, the Director of Standards Development MAY agree to Call for Review of a Proposed Recommendation even without adequate implementation experience;
Satisfied any other announced entrance criteria (e.g., any included in the request to promote to Candidate Recommendation, or announced at Last Call if the Working Group does not intend to issue a Call for Implementations).

Duration of the review: The announcement begins a review period that MUST last at least 45 days.

Ongoing work: During the review period, the WG requests endorsement and support from XBRL Participants (e.g., testimonials as part of a press release).

Possible next steps:

Forward: Publication as an XII Recommendation
Otherwise: Call for Implementations if there are questions related to implementation, return to Working Group or end work

7.5.5 Publication of a XII Recommendation

Document maturity level: Recommendation.

Announcement: The Director of Standards Development MUST announce the publication of a XII Recommendation to the public.

Rationale: XII publishes Recommendations when it believes that the ideas in the Technical Work Product are appropriate for widespread deployment and that they are in conformance with the strategic direction set down by the ISC.

Entrance criteria: The Director of Standards Development publishes an XII Recommendation upon request of the XSB and upon approval of that request from the ISC .

Possible next steps:

End state: A Technical Work Product MAY remain a Recommendation indefinitely
Otherwise: Modification of a Recommendation or Rescinding a Recommendation

The Director of Standards Development MAY submit a XII Recommendation to another standards body for adoption and formal approval by that body upon request from the XSB or the ISC.

7.5.6 Returning a Document to a WG for Further Work

A Technical Work Product is returned to a WG for further work in either of the following situations:

The WG makes substantive changes to the Technical Work Product at any time after a Last Call announcement and prior to Publication as a Recommendation, except when the changes involve the removal of features at risk identified in a Call for Implementations. In the case of substantive changes, the Working Group MUST republish the Technical Work Product as a Working Draft.
The XSB requires the Working Group to address important issues raised during a review or as the result of implementation experience. In this case the XSB MAY request that the Working Group republish the Technical Work Product as a Working Draft, even if the Working Group has not made substantive changes.

After re-publication as a Working Draft, the next forward step available to the Working Group is a Last Call announcement. The Last Call announcement MAY occur at the same time as the publication of the Working Draft.

The XSB MAY ask the WG to republish a Technical Work Product as a Candidate Recommendation. Simultaneously, the Director of Standards Development issues a Call for Implementations.

7.6 Ending Work on a Technical work product

Work on a Technical Work Product MAY cease at any time. When a WG completes its work on a technical work product, it publishes it either as a Recommendation or a Working Group Note. For example, a WG might publish several Working Drafts of a requirements document, and then indicate that it no longer plans to work on the requirements document by publishing a Working Group Note.

Work MAY also cease because the XSB determines that the WG cannot productively carry the work any further. For example, the WG might have been closed, the participants might lose interest in a technical work product, or the ideas might be incorporated in another technical work product. If the XSB decides to discontinue work on a Technical Work Product before completion, the incomplete Technical Work Product SHOULD be published as a Working Group Note.

Possible next steps:

End state: A Technical Work Product MAY remain a Working Group Note indefinitely
Otherwise: A WG MAY resume work on the Technical Work Product as a Working Draft if directed to do so by the XSB.

7.7 Modifying an XII Recommendation

XII works to maintain its Recommendations (e.g., by tracking errata, providing test-bed applications, and helping to create test suites) and to encourage widespread implementation. The following sections deal with the management of errors and the process for making normative changes to a Recommendation.

7.7.1 Errata Management

Tracking errors is a critical part of a WG’s ongoing care of a Recommendation; for this reason, the scope of a WG charter SHOULD generally allow time for work after publication of a Recommendation. Alternatively such ongoing maintenance MAY be carried out by a separate WG whose charter specifically states that as its purpose, as determined by the XSB. In this Process Document, the term “erratum” (plural “errata”) refers to any class of mistake, from simply editorial to a serious error that may affect the conformance with the Recommendation by software or content (e.g., XBRL instance or taxonomy validity).

Note: Before a document becomes a Recommendation, the process focuses on substantive changes (those related to prior reviews). After a document has been published as Recommendation, the process focuses on those changes to a Technical Work Product that might affect the conformance of content or deployed software.

WGs MUST track errata internally in a list of enumerated error reports [7], possibly accompanied by corrections.

A correction is first “proposed” by the WG. A correction becomes normative -- of equal status as the text in the published Recommendation -- through one of the processes described below. The WG publishes updated “errata corrected” versions of the Technical Work Product at intervals as necessary and as approved by the XSB.

A WG SHOULD keep their tracked errata up-to-date, as errors are reported by readers and implementers. A WG MUST report changes in tracked errata to interested parties when corrections are proposed or become normative.

7.7.2 Classes of Changes to a Recommendation

There are 4 classes of change to a Recommendation.

1. No changes to text content

These changes include fixing broken links or invalid markup.

2. Corrections that do not affect conformance

Editorial changes or clarifications that do not change the technical content of the specification.

3. Corrections that MAY affect conformance, but add no new features

These changes MAY affect conformance to the Recommendation. A change that affects conformance is one that:

turns conforming data, processors, or other conforming agents into non-conforming agents, or
turns non-conforming agents into conforming ones, or
resolves an ambiguity or under-specified part of the specification in such a way that an agent whose conformance was once unclear becomes clearly conforming or non-conforming.

4. New features

The first two classes of change do not require technical review of the proposed changes, although a WG MAY issue a Call for Review. The modified Recommendation is published upon approval by the XSB. The publication MUST include a both a normative version of the Work Product that includes the accumulated effect of all the changes resulting from errata corrections, and a marked up version indicating the details of the changes resulting from errata corrections compared against the original Recommended version of the Work Product.[8]

For the third class of change, the following is required:

Review by both XBRL Participants and the general public to ensure the technical soundness of proposed corrections.
Timely publication of the edited Recommendation, with corrections incorporated.

For this third class of change, the WG MUST request that the Director of Standards Development issue a Call for Review of an Edited Recommendation.

For the fourth class of change (new features), a WG MUST follow the full process of Promoting a Technical Work Product to Recommendation.

7.7.3 Call for Review of an Edited Recommendation

Document maturity level: Proposed Edited Recommendation.

Announcement: The Director of Standards Development MUST announce the Call for Review to other XII WGs, the public, and the XSB. The announcement MUST clearly indicate that this is a proposal to edit a Recommendation and MUST:

specify the deadline for review comments;
identify known dependencies and solicit review from all dependent WGs;
solicit public review.

Rationale: At this step, confirmation of proposed corrections to a Recommendation is being sought.

Entrance criteria: The Director of Standards Development calls for review when satisfied that, with respect to changes to the document, the WG has fulfilled the same entrance criteria as for a Call for Review of a Proposed Recommendation (e.g., the WG can show implementation experience that supports the changes). In the request to advance to this status, the WG MUST report any substantive issues about the Technical Work Product that have not been resolved.

Duration of the review: The announcement begins a review period that MUST last at least four weeks.

Ongoing work: During the review period, the WG solicits and responds to comments from XBRL Participants, other XBRL WGs, and the public.

Possible next steps:

Forward: Publication of a XII Recommendation
Otherwise, the Recommendation remains unchanged and two steps are possible: return to Working Group or end work

7.8 Rescinding an XII Recommendation

At times, XII MAY rescind an entire Recommendation, for instance when it learns of significant errors in the Recommendation, when the Recommendation becomes outdated, or if burdensome patent claims that affect implementers are discovered.

To deprecate part of a Recommendation, the process for modifying a Recommendation is followed.

Once a Recommendation has been rescinded, future XII technical work products MUST NOT include normative references to that technical work product.

7.8.1 Proposal to Rescind a Recommendation

Document maturity level: Recommendation, plus separate rationale for the proposal to rescind.

Announcement: The Director of Standards Development MUST announce the Proposal to Rescind a Recommendation to other XII WGs, the public, and the XSB. The announcement MUST clearly indicate that this is a Proposal to Rescind a Recommendation and MUST:

specify the deadline for review comments;
identify known dependencies and solicit review from all dependent WGs;
solicit public review.

Rationale: At this step, XII seeks confirmation of a Proposal to Rescind a Recommendation.

Entrance criteria: The Director of Standards Development proposes that XII rescind a Recommendation when satisfied that there is sufficient reason.

Duration of the review: The announcement begins a review period that MUST last at least four weeks.

Ongoing work: During the review period, the WG solicits and responds to comments from XBRL Participants, other XII WGs, and the public.

Possible next steps:

Forward: Publication of a Rescinded Recommendation
Otherwise: The Recommendation remains unchanged and two steps are possible: return to Working Group or end work

7.8.2 Publication of a Rescinded Recommendation

Document maturity level: Rescinded Recommendation.

Announcement: The Director of Standards Development MUST announce the Publication of a Rescinded Recommendation to the public.

Rationale: At this step, XII indicates that it no longer endorses a previously published Recommendation.

Entrance criteria: The Director of Standards Development publishes a Rescinded Recommendation when directed to do so by the XSB or the ISC.

End state: A Technical Work Product MAY remain a Rescinded Recommendation indefinitely

7.9 General Information about Technical work products

Every document published as part of the Technical Work Product development process MUST be a public document. XII will make every effort to make archival documents indefinitely available at their original address in their original form.

Every document published as part of the Technical Work Product development process MUST clearly indicate its maturity level.

Every Technical Work Product published as part of the Technical Work Product development process is edited by one or more editors appointed by a Working Group Chair. It is the responsibility of these editors to ensure that the decisions of the group are correctly reflected in subsequent drafts of the technical work product. All XII editors MUST be members of the group responsible for the document(s) they are editing.

The primary language for XII technical work products is UK English. XII encourages the translation of its technical work products.

7.9.1 Document Status Section

Each Technical Work Product MUST include a section about the status of the document. The status section SHOULD explain why XII has published the technical work product, expectations about next steps, who developed it, where to send comments about it, whether implementation experience is being sought, any significant changes from the previous version, why work on the Technical Work Product has ceased, and any other relevant information or rationale.

[1] There are other consortia that could potentially be used as sources of input for XII processes but it is felt that OASIS and the W3C are sufficient when coupled with XII’s own knowledge and experience of its operations over the past few years. It is felt that extensive review of additional consortia would be counterproductive and unnecessary.

[2] The definition of “open standard” is the subject of some considerable debate and not appropriate to discuss in this document – however such precise definition is not necessary for the understanding of this document and the reader is invited to use whatever definition they are comfortable with in understanding this document.

[3] The term “Review Team” is not necessarily part of the name of any such group.

[4] “mandatory” means that the component MUST form part of the Technical Work Product

[5] “normative” means that the component is what implementers of the work product can refer to in order to determine unambiguously the correctness of their implementation. Often there may be normative and non-normative versions of work product (such as translations into different languages which are usually non-normative) or additional work product such as training materials or introductory guides that can be usefully referred to. However, in the event of any discrepancy in the information provided in material marked non-normative and that marked normative, the material marked normative supersedes that marked non-normative.

[6] “optional” means “not mandatory”

[7] Such as the “Bugzilla” incident tracking system

[8] Using, for example, change tracking features of commonly available software.

XBRL International Technical Working Group and Work Product Process – 2007-04-17

TABLE OF CONTENTS

0 Introduction

1 Background

2 Sources of input[1]

3 Document structure

4 Organisational components and their interrelationships

5 Definitions

6 Working Group life cycle and internal processes

6.1 WG eGroups

6.2 WG Formation

6.3 First WG Meeting of a WG

6.4 WG Membership and Participation

6.5 Termination of WG Membership

6.6 Leaves of Absence

6.7 WG Chairs and Vice-Chairs

6.8 WG Visibility

6.9 WG Procedure

6.10 WG Meetings

6.11 WG Charter Clarification

6.12 WG Rechartering

6.13 WG Voting

6.14 WG Subcommittees

6.15 Closing a WG

6.16 Intellectual Property Rights Procedures

6.17 Specification Quality

6.18 Application to Existing WGs

7 XII Technical Work Product Development Process

7.1 Technical Work Product

7.2 Maturity Levels

7.2.1 Maturity Level for Work in Progress

Working Draft (WD)

Working Group WD (WGWD)

Internal WD (IWD)

Public WD (PWD)

7.2.2 Maturity Levels of the Recommendation Path

Candidate Recommendation (CR)

Proposed Recommendation (PR)

XII Recommendation (REC)

7.2.3 Maturity Level for other publications about a Technical Work Product

Working Group Note

7.2.4 Maturity Level When Ending Work on a Technical Work Product

Final Working Group Note

7.2.5 Maturity Level When Editing a Recommendation

Proposed Edited Recommendation

7.2.6 Maturity Levels When Rescinding a Recommendation

Rescinded Recommendation

7.3 General Requirements for Promotion on the Recommendation Path

7.4 Reviews and Review Responsibilities

7.5 Promoting a Technical Work Product to Recommendation

7.5.1 First Public Working Draft

7.5.2 Last Call Announcement

7.5.3 Call for Implementations

7.5.4 Call for Review of a Proposed Recommendation

7.5.5 Publication of a XII Recommendation

7.5.6 Returning a Document to a WG for Further Work

7.6 Ending Work on a Technical work product

7.7 Modifying an XII Recommendation

7.7.1 Errata Management

7.7.2 Classes of Changes to a Recommendation

7.7.3 Call for Review of an Edited Recommendation

7.8 Rescinding an XII Recommendation

7.8.1 Proposal to Rescind a Recommendation

7.8.2 Publication of a Rescinded Recommendation

7.9 General Information about Technical work products

7.9.1 Document Status Section

2 Sources of input [1]