1. Introduction

The Inline XBRL Style Guide is intended to assist commercial and in - house software developers engaged in the process of producing applications that create one or both of the Inline XBRL components of an online Company Tax Return (i.e. a Tax Computation and/or a set of Statutory Accounts). It does not cover information relating to the Company Tax Return itself (the CT600 andits supplementary pages) or the mechanisms of online filing - for these, please refer to the ‘Tech Pack’ for CT online filing, published by HMRC’s Software Developer SupportTeam (SDST) at

http://www.hmrc.gov.uk/ebu/ct-tech-index.htm.

The information and guidance presented here is not mandatory (except where it relates to requirements of the Specification itself or the HMRC online service) but is intended to ssist developers in producing Inline XBRL documents that are as complete and useful as possible.

This Guide should be read in conjunction with the Inline XBRL 1.0 Background Information and Guidance document produced by the XII1 Rendering Working Group, which is intended as a non-normative companion to the Specification itself - the 6th Candidate Recommendation version of the background document can be found at:

http://www.xbrl.org/Specification/inlineXBRL/CR-2009-11-16/inlineXBRL-background-CR-2009-11-16.html.

2. Conformance with the Inline XBRL Specification

The HMRC CT online service (launched on 23rd Nov 2009) is currently conformant with the 4th Candidate Recommendation (April 2009) of the Inline XBRL Specification. There is a later (5th) Candidate Recommendation that adds a feature (escaped HTML in nonNumeric elements) that is of no relevance to the HMRC CT online service.

A 6th Candidate Recommendation was released in November 2009, with one additional (backwards - compatible) feature of use to users of the HMRC CT online service (discussed more fully in thesection on ‘Duplication of marked - up facts’below). The 6th Candidate Recommendation can be found at:

http://www.xbrl.org/Specification/inlineXBRL-part1/CR-2009-11-16/inlineXBRL-part1-CR-2009-11-16.html.

A Proposed Recommendation is expected to be published in early 2010, at which point the Specification is effectively frozen. Eventually the Specification will reach Recommendation status.

Any update to the HMRC CT online service to align with a later version of the Specification will be signalled well in advance, and will be applied to the test service first. The XII Rendering Working Group (the body that controls the Specification) is taking care to ensure that any changes from the 4th Candidate Recommendation onwards are backwards-compatible so that Inline XBRL production software already “in the field”is not invalidated by new Candidate Recommendations.

3. Document level Issues

3.1  Multiple input documents

The vast majority of Tax Computations and Accounts supplied by vendor applications are expected to be single, self-contained Inline XBRL documents that can be opened and viewed in a single browser window. However, for practical reasons, multiple Inline XBRL documents (sometimes referred to as an Inline XBRL Document Set, or IXDS)  are allowed by the service (the CT600 XML Schema permits multiple iXBRL instance documents to be presented in a single submission for each of the Tax Computation and the Accounts).

The potential for generating “oversized” Inline XBRL documents is the only reason to create a document set as opposed to a single Inline XBRL document. Experience has shown that XHTML documents larger than about 5mb in size present difficulties for most current web browsers, so for the sake of your customers and HMRC staff, arrange to break up Inline XBRL documents that may approach this size.

There are however some extra things to think about with multiple input documents. First, give dueconsideration to navigation between documents-you may have a summary document with links to all the detailed parts, or you may simply chain two or more documents together. Either way, navigation links must be implemented with relative URLs so that they continue to function correctly within HMRC’s environment-absolute URLs containing your customer’s domain are not going to resolve properly. It is best to avoid sub-directories and keep the collection of documents in a single directory- that way the navigation URLs only depend on the preservation of the original filenames,which will have to be supplied as attributes2.

One, and only one, of the documents in the set will have to be nominated as the “entry point” via an attribute on its < InlineXBRLDocument > or < EncodedInlineXBRLDocument > element. This is the document that you want the user to see first when opening and viewing the document set. Multiple input documents with no nominated “entry point” will be rejected, as will multiple input documents with more than one nominated “entry point” (for single input documents there is no need to provide the “entry point” attribute at all).

3.2  Single output document

The result of processing one, or a set of related, Inline XBRL “input” document(s) in a submissionis always a single target XBRL instance document. Multiple target XBRL instance documents are not supported by the service, despite being permitted by the Inline XBRL Specification.

The consequence is that the service will always derive a single XBRL instance document for the Tax Computation (where supplied) and a single XBRL instance document for the Accounts (where supplied) even if those instance documents refer to concepts defined in multiple Taxonomies (e.g. when using the Common Data Taxonomy in conjunction with an accounts Taxonomy, or when a private extension Taxonomy is supplied).

3.3  XHTML vs HTML

The Inline XBRL Specification is designed to allow Inline XBRL to work with either HTML or XHTML. The choice of XHTML for the HMRC CT online service is made for us by the UK Govt Gateway, which expects submission payloads to be well-formed XML. Only XHTML meets this requirement.

As a consequence you should ensure that the < html > root element of your Inline XBRL document is in the XHTML namespace. This is usually achieved by setting the default namespace for the document, thus:

xmlns='http://www.w3.org/1999/xhtml'

in addition to all the other namespace declarations required for Inline XBRL use. In articular, an Inline XBRL document is recognised by the presence of one or more elements that have the “http://www.xbrl.org/2008/inlineXBRL” namespace name.

The provision of a DOCTYPE declaration for Inline XBRL documents is not recommended-in many processing situations this will lead to an unsuccessful attempt to validate the document against a DTD. A full modular Schema for the Inline XBRL extension to XHTML is available, a full Inline XBRL DTD is not.

The XHTML version attribute may be used to identify a document as Inline XBRL, but it is not recommended. If used, the value must be the Formal Public Identifier “ -//XBRLInternational//DTD XHTML InlineXBRL0.1//EN ”, but note that when the Inline XBRL Specification moves to Proposed Recommendation status the version component of this Identifier will change to 1.0 from 0.1, and when the HMRC CT online service follows suit the old Identifier string will cease to be recognised, invalidating previously valid Inline XBRL documents.

The use of XHTML also allows more rigorous checking of the mark-up (including the Inline XBRL mark-up elements) against the XHTML modular Schema, reducing the likelihood of HMRC accepting Inline XBRL that renders slightly differently in different browsers.

3.4  Document Encoding & Use Of “non-standard” Characters

The UK Govt Gateway expects submission payloads to be UTF‐83 encoded, and so Inline XBRL documents submitted to the HMRC CT online service must also be UTF‐8 encoded by default.

If your Inline XBRL document is to be used standalone (e.g. as a saved version of the submitted document) then it is advisable to provide an initial XML declaration that explicitly sets the document encoding to UTF‐8, thus:

This will ensure that web browsers treat the document as intended and render any embedded, multi-byte UTF-8-encoded characters correctly. HMRC systems will always reat the content as UTF-8 encoded, so this ensures that character renderings are consistent on both sides of the fence.

When embedding an Inline XBRL document in the CT600 < InlineXBRLDocument > or < EncodedInlineXBRLDocument > element the XML declaration must be removed. The complete XML transaction (rooted at < GovTalkMessage >) should have an initial XML declaration containing ‘ encoding= ” utf‐8 ””” which will apply to the transaction document as a whole.

There are two principal methods of including “non-standard”(a euphemism for characters that fall outside of the ASCII 7-bit character set) characters in Inline XBRL documents (such characters may include currency symbols, simple graphic symbols, accented characters, etc). The first is to use the appropriate UTF-8 encoding, which will usually (but not always) be a two-byte value, both of which will have their top (i.e. 8th) bit set. So long as the document encoding is correctly set then browsers or other display tools will be able to interpret these bytes correctly as the appropriate character. However, be aware that text editors and other display tools that don’t understand document encodings and treat the content as 7-bit ASCII will not display UTF-8 encoded characters correctly,and if used to modify a document with embedded UTF-8 encoded haracters may actually destroy or alter the encoding such that it no longer renders correctly in UTF-8-aware applications.

To avoid such eventualities, if needs be, the second method may be employed. XML (of which XHTML is an application) provides for escaped character references of the form “ &#xxxx ;” where “ xxxx ” may be replaced by a decimal number representing the Unicode code point (see http://wikipedia.org/wiki/Code_point for more details) of the character glyph to be displayed. For example, here are some common symbol glyphs and their character reference equivalents:

(pound sign)  & # 163;

(euro sign)    & # 8364 

(copyright)    & # 169;

Such code point values are also encoded into the bytes of a UTF-8 encoded multi-byte character -you can think of an XML character reference and a UTF-8-encoded character as two alternative ways of specifying a Unicode code point, which in turn represents a particular character glyph. 

The advantage of the second method is that non-UTF-8-aware text editors and text

isplay tools will not disrupt or damage the character references, though they will not  d

be displayed as intended.

The exceptions to the rule are the five characters special to XML mark-up: ‘ < ’, ‘ > ’, ‘ & ’, ‘’’  and  ‘’’’. Their ASCII character representations are UTF-8 compatible, so to protect them from interpretation by XML-aware processors, XML provides five named character entities to escape them (“&lt;”, “&gt;”, “ & ”, “ &apos; ” and “ &quot; ”). You can use these named character entities in preference to the five equivalent numeric character references if you wish.

It is recommended that you avoid using named character entities aside from these five “special” ones. Named character entities are usually defined in a DTD (Document Type Definition) and the XHTML DTD defines quite a number of them. However, Inline XBRL does not have a fully defined DTD (the preference being for the modular XHTML Schema) meaning that the interpretation of these named entities becomes browser dependent.

3.5  Java Applets, JavaScript

Java applets, JavaScript, and any other HTML < script > content, is embedded code executed by a browser or other rendering engine, and presents an unacceptable security risk for HMRC internal systems. It is therefore not possible to submit Inline XBRL documents with embedded applets or script fragments of any kind either to animate the document or enhance the look & feel of the document.

Tax Computations and Accounts are not documents that have traditionally been adorned with dynamic content or sophisticated presentation (at least not for regulatory purposes!). House styles or particular look & feels are best achieved with CSS – see below.

3.6  CSS styling

Cascading Style Sheet (CSS) language is the de facto standard means by which stylistic information is added to the rendering of (X)HTML documents by web browsers and users of the HMRC CT online service have free rein to style Inline XBRL documents using it in any way they see fit.

If CSS is required it must be embedded in the Inline XBRL document directly. It is not possible to provide a separate (.css) file for inclusion, even with multiple Inline XBRL input documents. In these cases, duplicate the CSS declarations as necessary in each input document. If you are using multiple Inline XBRL input documents because of the size of the submission document the duplicate CSS script is hardly going to make matters worse.

3.7  Pagination

Inline XBRL documents submitted to the HMRC CT online service will not be printed within HMRC as a matter of course, but there will be occasions when it is appropriate or necessary to do so. To facilitate this, page breaks should be inserted at appropriate points in the Inline XBRL document to ensure that printed output looks as neat and as presentable as possible. Page breaks should beinserted before major headings, tables, front sheets, etc. to ensure that, as much as possible, important information isn’t spread over a physical page boundary. These breaks should mirror the page breaks inserted by generating applications when producing local renderings in other formats (e.g. plain text, PDF, Word).

In XHTML, “page break before” and “page break after”styles can be applied to mark-up elements directly, thus:

They can also be included in macros and bound to elements of a particular class. Example (1) above forces a page‐break after the content between the paragraph tags has been output, and example (2) above forces a page‐break before the table is output. For a full list of page‐breaking styles, their values and their resulting behaviours please refer to documentation or reference material for CSS.

3.8  Images, logos, etc

Within the HMRC environment there is no scope to refer to external image files by URL, so any logos or small images that are integral to the look & feel of a submitted Inline XBRL document should be inlined as a base64‐encoded string in the URI value normally used to reference an image file using the ‘data’ URI scheme. E.g.:

where ‘xxx…xxx’ is the base64-encoding of the image whose mime-type is ‘image/png’ 

(GIF, JPG and PNG are the only widely supported image formats).

This technique is manageable with relatively small images, logos, etc., but should beused sparingly to avoid bloating the overall Inline XBRL document. If an image is required in more than one location it is possible to create a CSS macro utilising the background:url style and passing it the inlined URI. E.g. (assuming a 100x100 pixel image):

This technique ensures that only one physical instance of a base64‐encoded image is included in an Inline XBRL document. Support for inlined images in web browsers is widespread but not universal-check your intended target browser audience carefully before embarking upon the use of this feature.

3.9  XML Canonicalisation

Since XHTML is legal XML it will canonicalise (for the purposes of HMRC IRmark creation) successfully, though as with other HMRC services that support IRmark, the explicit canonicalisation step can, with care, simply be avoided by generating canonical XML (XHTML) in the first place. With large Inline XBRL (i.e. XHTML) documents that cannot be generated in canonical form the performance of client‐side canonicalisation may leave something to be desired -if this is the case the canonicalisation step can be avoided, at the cost of an encoding step, by using the CT600 XML < EncodedInlineXBRLDocument > element in preference to the element and providing a base64‐encoded string version of the Inline XBRL document instead. Base64-encoded Inline XBRL documents are decoded by the HMRC CT online service and treated identically to “ordinary” Inline XBRL documents (except where the Inline XBRL document is not well-formed XML-an error will be raised by HMRC’s validation system rather than by the Govt Gateway).

Inline XBRL introduces a number of extra and unfamiliar namespace declarations and attributes-care should be taken to make sure that all namespace declarations and attributes are ordered correctly and all superfluous namespace declarations are removed (see the document ordering section of the XML Canonicalisation Spec: http://www.w3.org/TR/xml-c14n#DocumentOrder for details).

3.10  Percentages

The conventional representation of a percentage value in an Inline XBRL document can be achieved easily, whilst still preserving the underlying meaning of the value as a decimal fraction (for calculation relationships, etc). However, in presentation terms, the choice of one or the other is down to the preference of the preparer (or the preparer’s software).

The Inline XBRL scale attribute can be used to effect a transformation from the conventional representation in the Inline XBRL document to a decimal fraction in the target XBRL instance document. A scale of ‘-2’ will transform a value such as ‘28%’into the equivalent decimal fraction ‘0.28’. A unit based on ‘pure’ should be applied to any percentage values. For example, given the following line item in an Inline XBRL rendering:

First Year tax Rate         28%

the value 28% is marked up as follows: 

Note that the percent sign itself occurs outside of the Inline XBRL mark up.

4. Element level Issues

4.1  Transformation rules

The Inline XBRL Transformation Rules Registry, which is Part 3 of the Inline XBRL Specification, defines all the transformation rules that are applied to displayed fact values in an Inline XBRL document to turn them into canonical XSD type representations suitable for inclusion in the resulting XBRL target document. For completeness, the current transformation rules, at the time or writing, are enumerated here with an explanation of the effect of each one:

●  numcomma       Re-formats numbers using comma as fraction separator 

into XSD non-negative decimal type 

●  numcommadot    Re-formats numbers using commas as thousands separator 

and dot as fraction separator into XSD non-negative 

decimal type 

●  -numdash        Re-formats accounting notation ‘-‘as value zero in XSD non-

negative decimal type 

●  numdotcomma    Re-formats numbers using dot as thousands separator and 

comma as fraction separator into XSD non-negative decimal

type 

●  numspacedot     Re-formats numbers using space as thousands separator 

and dot as fraction separator into XSD non-negative 

decimal type 

●  numspacecomma  Re-formats numbers using space as thousands separator 

and comma as fraction separator into XSD non-negative 

decimal type 

●  dateslashus       Re-formats a US-style slash-separated date 

(MM/DD/(YY)YY) into XSD date format 

●  dateslasheu      Re-formats a EU-style slash-separated date 

(DD/MM/(YY)YY) into XSD date format 

●  datedotus        Re-formats a US-style dot-separated date

 (MM.DD.(YY)YY) into XSD date format  

●  datedoteu        Re-formats an EU-style dot-separated date 

(DD.MM.(YY)YY) into XSD date format 

●  datelongus       Re-formats a US-style long date (Month DD, (YY)YY) into 

XSD date format  

●  datelonguk       Re-formats a UK-style long date (DD Mon (YY)YY) into XSD

date format 

●  dateshortus      Re-formats a US-style short date (mon DD, (YY)YY) into 

XSD date format 

●  dateshortuk      Re-formats a UK-style short date (DD mon (YY)YY) into XSD 

date format 

Note that the Registry may grow over time as new transforms are added, and you are advised to check the latest version for an up to date list. 

4.2  Duplication of marked‐up facts

The 4th Inline XBRL Candidate Recommendation, to which the HMRC CT online service current conforms, does not provide for any automatic de-duplication of identical facts during transformation to the target XBRL document. This allows non-tuple-member Marked-up facts to be legally duplicated in the Inline XBRL document because duplicate non-tuple-member facts are permitted in the target XBRL document.

However, only one occurrence of a set of duplicate tuple‐member facts may be marked up. This is a limitation of the current HMRC CT online service designed to avoid the inadvertent violation of tuple content models that might lead to a Schema‐invalid target XBRL document. Attempts to mark‐up duplicate tuple‐member facts (i.e. those belonging to the same tuple and with identical order attribute values) will therefore be rejected by the HMRC CT online service. If you have multiple occurrences of a tuple‐member fact in an Inline XBRL document then you must choose (arbitrarily if necessary) one of the occurrences to mark‐up as Inline XBRL, and leave the remainder as XHTML only. You may, if you wish, provide internal document hyperlinks from the marked-up occurrence to the other occurrences to aid the reader/reviewer.

It is acknowledged that this is an annoying restriction that has implications for document assurance, which is why the 6th Inline XBRL Candidate Recommendation provides a mechanism to allow conforming processors to de-duplicate identical tuple-member facts. This will allow document creators to mark‐up all duplicate facts regardless of their status as tuple members or independent concepts. Duplicate facts that are not tuple members may still be present in the target XBRL document, but this is not illegal XBRL, though downstream processing will need to take them into account.

The HMRC CT online service will be upgraded to the 6th Candidate Release at a suitable point in the near future and HMRC will provide notice of this so you can prepare to take advantage of it. The step up from the 4th to the 6th Candidate Recommendation preserves backwards-compatibility and will not break Inline XBRL production applications compliant with the 4th Candidate Recommendation that are already being used by your customers.

4.3  Escaped HTML in non-numeric data

A later Inline XBRL Candidate Recommendation (the 5th to be precise) allows textual data in a nonNumeric marked-up fact to contain ‘escaped’ (X)HTML formatting. This is  not a feature of the Specification that will be supported by the HMRC CT service.

Any (X)HTML mark‐up in a nonNumeric element will be eliminated, and leading and trailing whitespace removed, before transformation to the target XBRL instance document value.

4.4  Number Signs

Numbers represented in XBRL (and Inline XBRL) are generally positive in value, notwithstanding the value of the ‘balance’ attribute in the concept’s definition, which is usually of use only in calculation relationships. Where a genuine negative value is required in the target XBRL document (e.g. to show a loss for a concept that is defined in terms of profit) the ‘ sign ’attribute in the Inline XBRL mark‐up should be used to indicate this.

The representation of the sign in the Inline XBRL document rendering is completely separate and is a function of the XHTML mark‐up that surrounds the marked-up fact. That mark-up might indicate a negative value with surrounding brackets, or by a leading minus sign, or by changing the font to red (or a combination of these) – the point is that none of these adornments, by themselves, have any influence over the sign of the value that ends up in the target XBRL document, which by default will be positive unless the sign attribute is used as an indicator.

The following examples should illustrate the differences:

a.  Negative underlying value with negative portrayal

The monetary fact representing a loss in a statement of the form:

Profit (Loss) before Tax      (345,678)

in the Inline XBRL rendering of a set of Accounts might be marked up in the Inline XBRL document as a table data item as follows:

Note that the brackets are outside the Inline XBRL mark‐up so as not to interfere with the value that is transformed for the target XBRL instance document. The presence of the sign attribute results in a negative value in the resulting XBRL instance document that correctly indicates that the value represents a loss rather than a profit:

The item PBT would normally be defined in the Taxonomy with its balance set to ‘credit’ to indicate that where a profit is reported, it is naturally thought of as an increase in funds (i.e. a credit), and so a loss must be explicitly negated.

b.      Positive underlying value with negative portrayal

The monetary fact representing cost of sales in a statement of the form:

Cost of Sales      (123,456)

in the Inline XBRL rendering of a set of Accounts might be marked up in the Inline XBRL document as a table data item as follows:

Note that the brackets are outside the Inline XBRL mark‐up so as not to interfere with the monetary value that is transformed for the target XBRL instance document. However, in this case, the lack of a sign attribute results in a positive value in the resulting XBRL instance document that correctly indicates that the value represents a cost amount:

The item CostSales would normally be defined in the Taxonomy with its balance set to ‘debit’ to indicate that where a cost is reported it is naturally thought of as a decrease in funds (i.e. a debit) and so doesn’t need to be explicitly negated.

c.      Negative underlying value with positive portrayal

The monetary fact representing a cost of disposal in a statement of the form: 

Disposal Cost        45,678

in the Inline XBRL rendering of a set of Accounts might be marked up in the Inline

XBRL document as a table data item using a revenue tag as follows:

Note that in this (slightly contrived!) example the cost is being tagged as a negative revenue. The presence of the sign attribute results in a negative value in the resulting XBRL instance document that correctly indicates that the value represents a cost amount:

The item DisposalRevenue would normally be defined in the Taxonomy with its balance set to ‘credit’ to indicate that where revenue is reported it is naturally thought of as an increase in funds (i.e. a credit) and so in this case needs to be explicitly negated to show a cost.

5. XBRL‐related Issues

5.1  Minimum Tagging Requirement

In recognition of the effort that some software developers have to expend to provide a mapping between their internal application information model and the information models defined by the available Accounts filing Taxonomies, HMRC have created, in collaboration with XBRL UK, ‘minimum tagging requirements’ for UK GAAP and UK IFRS. These requirements, expressed as Presentation Linkbases in each Taxonomy, define a much-reduced set of XBRL tags for developers to work with, though if the mapping task is not so onerous for particular applications there is no reason why the full Taxonomy  cannot be used from the outset.

These Accounts Taxonomy minimum tagging requirements are transitional arrangements. By 2013 (probably), HMRC will phase out the minimum tagging requirements and expect full tagging of concepts that appear in the base Accounts Taxonomies (i.e. if you need to report a fact, and its concept definition appears in the relevant Accounts Taxonomy, it will need to be marked up regardless).

The minimum quirements for the Accounts Taxonomies are as follows:

The companion Common Data Taxonomy, which contains around 900 concept definitions, does not have a minimum tagging requirement, but typical Statutory Accounts documents will use only a handful of CD Taxonomy concepts anyway (marked up facts in an Inline XBRL document may be drawn from more than one namespace, and therefore more than one Taxonomy).

A similar minimum tagging requirement exists for the HMRC Tax Computation Taxonomy, but in this case the arrangement is not temporary. The Tax Computation Taxonomy dates from a time before Inline XBRL was envisaged, and was an attempt to provide a comprehensive Taxonomy for the complete XBRL mark‐up of a tax computation (even then private extension taxonomies were considered inevitable). The minimum tagging requirement for the Tax Computation Taxonomy is, in effect, the Tax Computation Taxonomy that would have been created in the Inline XBRL era. It contains just those concept definitions of interest to HMRC, eliminating a lot of detail that can now be provided simply as XHTML. However, the full Taxonomy remains in case software developers wish to mark up more detail (for whatever reason).

The Tax Computation Taxonomy contains about 4,500 concept definitions in total, whereas the minimum tagging requirement contains only 1,350 of these concept definitions.

5.2  Entity Identifier Scheme for HMRC submissions

All contexts referenced by marked up data items in submissions to HMRC should use the relevant Companies House Registration Number as the entity identifier value, and the scheme name ‘http://www.companieshouse.gov.uk’. E.g:

5.3  Document Creator Information

All software developers who have existing HMRC filing products will know that HMRC’s Software Developer Support Team recommend that vendor, product and version information is embedded in the GovTalk header of Gateway submissions. This enables SDS Team to provide filing statistics to individual vendors which identify how well (or badly!) their product is performing in the hands of real customers and where, if necessary, remedial action or improvement is required. The CT online service is no different in this regard, but the inclusion of Accounts produced by other software products into the filing envelope of another product presents difficulties.

To enable SDS Team to provide meaningful statistics to vendors of standalone Accounts production software packages we recommend that vendor, product and version information is embedded in the generated Inline XBRL document using the document  metadata tags from the Common Data Taxonomy.

For information relating to the product name and version number of an Accounts production software package using the 2008 Common Data Taxonomy use the uk-cd-pres:NameAuthor element, which is a component of an embedded tuple. The value should be the product name separated from the version number by a single space. E.g.:

This XBRL fragment (with all the other optional tuple members omitted) can be placed in the section of the generated Inline XBRL document to ensure that it is not visible in the rendered view of the document but is passed through into the target XBRL instance document.

Similarly, the website URL of the product vendor (which is all that is required to identify the vendor) can be provided in the uk-cd-pres:WebsiteURL element, which is also a component of an embedded tuple. E.g.:

The structure of the 2009 Common Data Taxonomy (incorporated in the 2009 UK GAAP Taxonomy) has changed somewhat. In this case we recommend using the single XBRLDocumentAuthorGrouping tuple for both data items, adopting the convention that the description element is used to carry the vendor’s website URL or company name: