HMRC Inline XBRL Style Guide V1.4

xbrl-style-guide-1.4

User Manual:

Open the PDF directly: View PDF .
Page Count: 20

Download
Open PDF In Browser	View PDF

v1.4	
  –	
  February	
  2011	
  
	
  
	
  
	
  
	
  

HMRC	
  CT	
  Inline	
  XBRL	
  Style	
  Guide	
  
Contents	
  
1.	
  Introduction	
  .................................................................................................................................	
  1	
  
2.	
  Conformance	
  with	
  the	
  Inline	
  XBRL	
  Specification	
  ........................................................	
  2	
  
3.	
  Document	
  level	
  Issues	
  .............................................................................................................	
  3	
  
3.1	
   Multiple	
  input	
  documents	
  ...........................................................................................	
  3	
  
3.2	
   Single	
  output	
  document	
  ...............................................................................................	
  3	
  
3.3	
   XHTML	
  vs	
  HTML	
  .............................................................................................................	
  3	
  
3.4	
   Document	
  Encoding	
  &	
  Use	
  Of	
  “non-­‐standard”	
  Characters	
  ...........................	
  4	
  
3.5	
   Java	
  Applets,	
  JavaScript	
  ................................................................................................	
  5	
  
3.6	
   CSS	
  styling	
  ..........................................................................................................................	
  6	
  
3.7	
   Pagination	
  ..........................................................................................................................	
  6	
  
3.8	
   Images,	
  logos,	
  etc	
  ............................................................................................................	
  6	
  
3.9	
   XML	
  Canonicalisation	
  &	
  Encoding	
  Submissions	
  ...............................................	
  7	
  
3.10	
   HTML	
  
	
  
or	
  
	
  
	
  

	
  
This	
  will	
  ensure	
  document	
  windows	
  can	
  be	
  quickly	
  located	
  and	
  uniquely	
  identified	
  by	
  
your	
  users	
  (who	
  may	
  be	
  agents	
  dealing	
  with	
  a	
  number	
  of	
  customers)	
  and	
  HMRC	
  staff	
  
alike.	
  
	
  

3.11	
   Hidden	
  data	
  items	
  
	
  
Inline	
  XBRL	
  provides	
  a	
  mechanism	
  (ix:hidden)	
  for	
  marking	
  up	
  data	
  items	
  that	
  do	
  not	
  
appear	
  on	
  the	
  face	
  of	
  a	
  document.	
  This	
  mechanism	
  should	
  be	
  used	
  as	
  sparingly	
  as	
  
possible	
  –	
  the	
  more	
  data	
  that	
  is	
  “hidden”	
  the	
  harder	
  it	
  is	
  to	
  assure	
  that	
  the	
  human	
  and	
  
computer	
  readable	
  data	
  items	
  in	
  the	
  document	
  are	
  aligned	
  –	
  when	
  they	
  are	
  one	
  and	
  the	
  
same	
  value,	
  alignment	
  is	
  assured.	
  
	
  
The	
  ix:hidden	
  section	
  of	
  an	
  Inline	
  XBRL	
  document	
  should	
  be	
  reserved	
  for:	
  
	
  
• The	
  declaration	
  of	
  tuple	
  container	
  elements	
  
• Document	
  metadata,	
  including	
  creator	
  information	
  (see	
  §5.3)	
  
• Boolean	
  items	
  not	
  directly	
  associated	
  with	
  statements	
  on	
  the	
  face	
  of	
  the	
  
document	
  (see	
  §4.9)	
  
• “Flag”	
  items	
  not	
  directly	
  associated	
  with	
  facts	
  on	
  the	
  face	
  of	
  the	
  document	
  (see	
  
§4.10)	
  
• Facts	
  that	
  do	
  not	
  normally	
  appear	
  on	
  the	
  face	
  of	
  the	
  document	
  
	
  
Furthermore,	
  the	
  use	
  of	
  HTML	
  or	
  CSS	
  text	
  hiding	
  mechanisms	
  other	
  than	
  that	
  
conventionally	
  used	
  to	
  protect	
  the	
  ix:hidden	
  section	
  from	
  view	
  or	
  implement	
  the	
  
Boolean	
  item	
  mark-­‐up	
  technique	
  described	
  in	
  §4.9	
  are	
  strongly	
  discouraged.	
  
	
  
If	
  in	
  doubt	
  follow	
  the	
  general	
  principle	
  that	
  if	
  a	
  fact	
  appears	
  on	
  the	
  face	
  of	
  a	
  document	
  
then	
  it	
  should	
  be	
  marked-­‐up	
  there	
  and	
  not	
  by	
  any	
  method	
  that	
  involves	
  the	
  hiding	
  of	
  
data	
  and	
  mark-­‐up.	
  

Page	
  8	
  of	
  20	
  
	
  

v1.4	
  –	
  February	
  2011	
  
	
  

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	
  Month	
  (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.	
  	
  
	
  
For	
  all	
  versions	
  of	
  the	
  Inline	
  XBRL	
  Specification	
  prior	
  to	
  the	
  final	
  Recommendation	
  the	
  
namespace	
  for	
  the	
  Transformation	
  Rules	
  Registry	
  is:	
  	
  
	
  
http://www.xbrl.org/2008/inlineXBRL/transformation	
  
	
  
Page	
  9	
  of	
  20	
  
	
  

v1.4	
  –	
  February	
  2011	
  
	
  
The	
  Transformation	
  Rules	
  Registry	
  namespace	
  for	
  the	
  final	
  Recommendation	
  is:	
  
	
  
http://www.xbrl.org/inlineXBRL/transformation/2010-­‐04-­‐20	
  	
  
	
  
The	
  change	
  to	
  introduce	
  a	
  date	
  component	
  is	
  intended	
  to	
  allow	
  future	
  updates	
  to	
  the	
  
Registry	
  to	
  be	
  separately	
  versioned	
  and	
  identified.	
  
	
  
At	
  present	
  the	
  correct	
  Transformation	
  Rules	
  Registry	
  namespace	
  is	
  the	
  former,	
  
unversioned,	
  URI.	
  The	
  latter,	
  versioned,	
  URI	
  is	
  not	
  recognised.	
  When	
  the	
  CT	
  online	
  
service	
  moves	
  to	
  final	
  Recommendation	
  conformance	
  the	
  versioned	
  URI	
  will	
  be	
  strongly	
  
preferred	
  though	
  the	
  two	
  will	
  be	
  completely	
  interchangeable.	
  However,	
  to	
  ensure	
  
backwards-­‐compatibility	
  the	
  unversioned	
  namespace	
  will	
  continue	
  to	
  be	
  supported	
  for	
  
a	
  period	
  of	
  at	
  least	
  a	
  year	
  to	
  allow	
  for	
  Inline	
  XBRL	
  generation	
  software	
  to	
  be	
  migrated.	
  
	
  

4.2

Duplication	
  of	
  marked-­‐up	
  facts	
  

4.2.1	
   De-­‐duplication	
  
The	
  4th	
  Inline	
  XBRL	
  Candidate	
  Recommendation,	
  to	
  which	
  the	
  HMRC	
  CT	
  online	
  service	
  
conformed	
  until	
  11th	
  October	
  2010	
  did	
  not	
  provide	
  for	
  any	
  automatic	
  de-­‐duplication	
  of	
  
identical	
  facts	
  during	
  transformation	
  to	
  the	
  target	
  XBRL	
  document.	
  This	
  allowed	
  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	
  could	
  be	
  marked	
  
up.	
  This	
  was	
  a	
  deliberate	
  limitation	
  of	
  the	
  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)	
  would	
  therefore	
  
have	
  been	
  rejected	
  by	
  the	
  HMRC	
  CT	
  online	
  service	
  prior	
  to	
  11th	
  October	
  2010.	
  	
  
	
  
The	
  Inline	
  XBRL	
  Proposed	
  Recommendation	
  provides	
  a	
  mechanism	
  to	
  allow	
  conforming	
  
processors	
  to	
  de-­‐duplicate	
  identical	
  tuple-­‐member	
  facts.	
  This	
  allows	
  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.	
  
	
  
The	
  step	
  up	
  from	
  the	
  4th	
  Candidate	
  Recommendation	
  to	
  the	
  Proposed	
  Recommendation	
  
(and	
  beyond,	
  to	
  the	
  final	
  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.2.2	
   Equivalence	
  

Identical	
  tuple-­‐member	
  facts	
  are	
  identified	
  as	
  such	
  by	
  a	
  simple	
  string	
  equivalence	
  test	
  –	
  
fact	
  values,	
  irrespective	
  of	
  their	
  type,	
  are	
  compared,	
  character	
  by	
  character,	
  after	
  being	
  
whitespace-­‐normalised.	
  Whitespace	
  normalisation,	
  which	
  is	
  equivalent	
  to	
  the	
  XML	
  
Schema	
  whiteSpace	
  facet	
  being	
  set	
  to	
  collapse,	
  involves	
  the	
  substitution	
  of	
  tabs,	
  linefeeds	
  
and	
  carriage	
  returns	
  by	
  the	
  space	
  character,	
  and	
  the	
  subsequent	
  conversion	
  of	
  multiple	
  
spaces	
  to	
  a	
  single	
  space.	
  Finally,	
  any	
  leading	
  or	
  trailing	
  spaces	
  are	
  eliminated.	
  For	
  
numeric	
  data	
  this	
  kind	
  of	
  normalisation	
  will	
  usually	
  have	
  no	
  effect,	
  but	
  for	
  text	
  it	
  ensures	
  
that	
  insignificant	
  whitespace	
  (line	
  breaks,	
  double	
  spaces,	
  etc)	
  is	
  generally	
  disregarded	
  
for	
  comparison	
  purposes.	
  
	
  
Page	
  10	
  of	
  20	
  
	
  

v1.4	
  –	
  February	
  2011	
  
	
  
This	
  kind	
  of	
  simple-­‐minded	
  equivalence	
  test	
  avoids	
  the	
  need	
  for	
  Inline	
  XBRL	
  processors	
  
to	
  be	
  aware	
  of	
  the	
  type	
  of	
  the	
  values	
  being	
  compared	
  (becoming	
  Taxonomy-­‐aware	
  
would	
  add	
  significant	
  overhead	
  to	
  the	
  performance	
  of	
  Inline	
  XBRL	
  processors)	
  but	
  there	
  
are	
  potential	
  pitfalls	
  –	
  numbers	
  expressed	
  to	
  different	
  levels	
  of	
  precision,	
  or	
  in	
  different	
  
mathematical	
  notations,	
  will	
  not	
  appear	
  to	
  be	
  equivalent	
  when	
  semantically	
  they	
  are.	
  	
  
	
  

4.3	
  

Escaped	
  HTML	
  in	
  non-­‐numeric	
  data	
  

The	
  Inline	
  XBRL	
  5th	
  Candidate	
  Recommendation	
  introduced	
  a	
  capability	
  to	
  allow	
  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.	
  
	
  
Normally,	
  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.	
  (X)HTML	
  mark-­‐up	
  in	
  any	
  other	
  Inline	
  XBRL	
  element	
  is	
  not	
  
permitted.	
  
	
  

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	
  differences3:	
  
	
  
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:	
  
	
  
(345,678)

	
  
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	
  

	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  
3	
  Items	
  names	
  deliberately	
  shortened	
  and	
  stripped	
  of	
  namespace	
  prefixes,	
  and	
  some	
  attributes	
  omitted,	
  to	
  
avoid	
  complicating	
  the	
  examples.	
  

Page	
  11	
  of	
  20	
  
	
  

v1.4	
  –	
  February	
  2011	
  
	
  
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:	
  
	
  
	
  	
  	
  	
  	
  	
  	
  	
  	
  -345678

	
  
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:	
  
	
  
	
  	
  	
  	
  	
  	
  	
  (123,456)
	
  

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:	
  
	
  
	
  	
  	
  	
  	
  	
  	
  123456
	
  
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:	
  
	
  
	
  	
  	
  	
  45,678
	
  

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:	
  
	
  
	
  
-45678
	
  

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.	
  
Page	
  12	
  of	
  20	
  
	
  

v1.4	
  –	
  February	
  2011	
  
	
  
	
  

4.5	
  

Scaling	
  and	
  Precision	
  

Numbers	
  may	
  be	
  conveniently	
  scaled	
  in	
  human-­‐readable	
  reports	
  to	
  show,	
  for	
  instance,	
  
figures	
  in	
  round	
  thousands	
  or	
  millions.	
  When	
  generating	
  human-­‐readable	
  output	
  
programatically	
  it	
  is	
  of	
  course	
  straightforward	
  to	
  ensure	
  that	
  if	
  scaling	
  is	
  required	
  the	
  
correct	
  precision	
  is	
  declared	
  and	
  the	
  correct	
  rounding	
  is	
  applied	
  to	
  the	
  value	
  to	
  ensure	
  
that	
  all	
  occurrences	
  of	
  the	
  same	
  fact	
  (whether	
  appearing	
  scaled	
  or	
  not)	
  remain	
  
equivalent	
  within	
  the	
  limits	
  of	
  their	
  declared	
  precisions.	
  
	
  
For	
  instance,	
  an	
  underlying	
  value	
  such	
  as	
  £1,234,567.89,	
  which	
  is	
  accurate	
  to	
  2	
  decimal	
  
places,	
  may	
  appear	
  rounded	
  to	
  the	
  nearest	
  pound	
  with	
  a	
  decimals	
  value	
  of	
  ‘0’	
  (i.e.	
  
£1,234,568),	
  rounded	
  to	
  the	
  nearest	
  thousand	
  with	
  a	
  decimals	
  value	
  of	
  ‘-­‐3’	
  and	
  a	
  scale	
  
value	
  of	
  ‘3’	
  (i.e.	
  £1,235),	
  or	
  rounded	
  to	
  the	
  nearest	
  tenth	
  of	
  a	
  million	
  with	
  a	
  decimals	
  
value	
  of	
  ‘-­‐5’	
  and	
  a	
  scale	
  value	
  of	
  ‘6’	
  (i.e.	
  £1.2).	
  The	
  latter,	
  when	
  un-­‐scaled	
  and	
  converted	
  
to	
  canonical	
  form	
  for	
  XBRL	
  would	
  result	
  in	
  a	
  value	
  of	
  £1,200,000	
  (accurate	
  to	
  -­‐5	
  decimal	
  
places),	
  which	
  nevertheless	
  is	
  “equivalent”	
  to	
  £1,234,567.89	
  (accurate	
  to	
  2	
  decimal	
  
places)	
  within	
  their	
  stated	
  accuracies.	
  However,	
  any	
  ‘higher’	
  value	
  for	
  decimals	
  (e.g.	
  ‘-­‐4’)	
  
would	
  result	
  in	
  an	
  inconsistency.	
  
	
  
Care,	
  however,	
  should	
  exercised	
  when	
  manually	
  marking	
  up	
  pre-­‐existing	
  financial	
  
reports.	
  The	
  original	
  author	
  will	
  have	
  applied	
  the	
  appropriate	
  scaling	
  and	
  rounding	
  
(correctly,	
  one	
  hopes)	
  and	
  it	
  is	
  the	
  responsibility	
  of	
  the	
  user	
  to	
  identify	
  the	
  correct	
  scale	
  
factor	
  to	
  declare	
  –	
  from	
  this	
  and	
  the	
  value	
  being	
  marked	
  up,	
  it	
  should	
  be	
  possible	
  for	
  
manual	
  tagging	
  applications	
  to	
  determine	
  the	
  necessary	
  decimals	
  value	
  to	
  set	
  an	
  
appropriate	
  precision.	
  If	
  rounding	
  has	
  been	
  mis-­‐applied	
  to	
  one	
  or	
  more	
  occurrences	
  of	
  
duplicate	
  values	
  in	
  the	
  original	
  document	
  (as	
  may	
  occur	
  when	
  summarising	
  more	
  
accurate	
  financial	
  data	
  from	
  the	
  body	
  of	
  a	
  report)	
  then	
  the	
  duplicate	
  values	
  may	
  be	
  
inconsistent	
  within	
  the	
  bounds	
  of	
  their	
  stated	
  accuracies.	
  Such	
  inconsistencies	
  may	
  
result	
  in	
  submission	
  rejection	
  or	
  increased	
  scrutiny	
  during	
  risk	
  analysis	
  within	
  HMRC.	
  

4.6	
  

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:	
  
	
  
28%

	
  
Page	
  13	
  of	
  20	
  
	
  

v1.4	
  –	
  February	
  2011	
  
	
  
Note	
  that	
  the	
  percent	
  sign	
  itself	
  occurs	
  outside	
  of	
  the	
  Inline	
  XBRL	
  mark	
  up.	
  Also	
  note	
  
that	
  as	
  per	
  the	
  previous	
  section	
  on	
  Scaling	
  and	
  Precision,	
  a	
  decimals	
  value	
  of	
  2	
  has	
  been	
  
set,	
  which	
  is	
  appropriate	
  for	
  the	
  two	
  significant	
  decimal	
  places	
  of	
  the	
  target	
  value	
  0.28	
  –	
  
it	
  bears	
  no	
  relationship	
  to	
  the	
  pre-­‐scaled	
  value	
  that	
  appears	
  in	
  the	
  rendering.	
  
	
  

4.7	
  

Nesting	
  Mark-­‐up	
  

The	
  Inline	
  XBRL	
  Specification	
  allows	
  the	
  nonNumeric	
  element	
  to	
  contain	
  other	
  Inline	
  
XBRL	
  mark-­‐up	
  so	
  that	
  where	
  narrative	
  text	
  is	
  marked	
  up	
  as	
  a	
  single	
  block	
  of	
  text	
  within	
  
a	
  single	
  string-­‐type	
  item	
  using	
  ix:nonNumeric	
  it	
  is	
  still	
  possible	
  to	
  mark-­‐up	
  embedded	
  
facts	
  so	
  that	
  they	
  appear	
  as	
  discrete	
  items	
  in	
  the	
  target	
  XBRL	
  instance	
  document,	
  in	
  
addition	
  to	
  the	
  item	
  representing	
  the	
  text	
  block	
  as	
  a	
  whole.	
  This	
  is	
  particularly	
  useful	
  
where	
  a	
  value	
  or	
  a	
  significant	
  name	
  is	
  mentioned	
  in	
  the	
  middle	
  of	
  a	
  paragraph	
  of	
  text	
  
(such	
  as	
  the	
  Director’s	
  Report	
  or	
  one	
  of	
  the	
  Notes	
  to	
  the	
  Accounts).	
  
	
  
For	
  example,	
  the	
  description	
  of	
  a	
  contingent	
  liability	
  with	
  an	
  embedded	
  current	
  period	
  
liability	
  figure	
  might	
  be	
  marked	
  up	
  as	
  follows:	
  
	
  

The company
operates a confidential invoice discount facility. The balance due on
this facility was £5,000 at 31st March
2010.

	
  

This	
  would	
  result	
  in	
  two	
  distinct	
  items	
  in	
  the	
  target	
  XBRL	
  document:	
  
	
  

	
  

The company operates a confidential
invoice discount facility. The balance due on this facility was £5,000 at
31st March 2010.

and	
  
	
  
5000

	
  
Note	
  that	
  the	
  figure	
  of	
  £5,000	
  is	
  repeated,	
  once	
  in	
  its	
  original	
  format	
  as	
  part	
  of	
  the	
  text	
  
description	
  item	
  (as	
  if	
  the	
  ix:nonFraction	
  mark-­‐up	
  was	
  not	
  there)	
  and	
  once	
  in	
  its	
  
canonical	
  form	
  in	
  the	
  numeric	
  item.	
  
	
  
This	
  technique	
  can	
  also	
  be	
  used	
  to	
  avoid	
  the	
  necessity	
  for	
  hidden	
  duplicate	
  description	
  
items	
  where	
  tuples	
  are	
  used	
  to	
  mark	
  up	
  tabular	
  data.	
  In	
  the	
  following	
  table	
  a	
  single	
  
description	
  relates	
  to	
  two	
  separate	
  monetary	
  values	
  for	
  current	
  and	
  previous	
  periods:	
  
	
  
	
  
	
  
	
  
	
  
	
  
	
  
2010	
   	
  
2009	
  
	
  
	
  
Line	
  Description	
  
	
  
£100	
   	
  
£200	
  
	
  
This	
  may	
  need	
  to	
  be	
  marked-­‐up	
  as	
  two	
  separate	
  tuples	
  –	
  one	
  for	
  each	
  period,	
  with	
  the	
  
description	
  repeated	
  for	
  each	
  one.	
  However,	
  only	
  one	
  description	
  appears	
  on	
  the	
  face	
  of	
  
the	
  document.	
  The	
  solution	
  is	
  to	
  nest	
  the	
  mark-­‐up	
  of	
  the	
  description:	
  
	
  


Page	
  14	
  of	
  20	
  
	
  

v1.4	
  –	
  February	
  2011	
  
	
  
Line Description 


100


200


	
  
This	
  results	
  in	
  four	
  items,	
  two	
  in	
  each	
  tuple,	
  in	
  the	
  target	
  XBRL	
  instance	
  document.	
  Each	
  
tuple	
  contains	
  a	
  description	
  item	
  and	
  a	
  value	
  item	
  (in	
  that	
  order)	
  where	
  the	
  description	
  
item	
  content	
  is	
  repeated	
  in	
  both.	
  
	
  
Note	
  that	
  the	
  contextrefs	
  for	
  the	
  items	
  in	
  tuple	
  ‘t1’	
  are	
  both	
  “CY”,	
  and	
  for	
  the	
  items	
  in	
  
tuple	
  ‘t2’	
  are	
  both	
  “PY”.	
  This	
  is	
  the	
  preferred	
  arrangement	
  (as	
  opposed	
  to	
  the	
  description	
  
item	
  in	
  one	
  or	
  both	
  cases	
  referring	
  to	
  the	
  alternate	
  contextref).	
  
	
  

4.8	
  

Tuple	
  Member	
  Ordering	
  

The	
  Inline	
  XBRL	
  Specification	
  deliberately	
  avoids	
  the	
  need	
  for	
  conformant	
  processors	
  to	
  
be	
  Taxonomy-­‐aware.	
  As	
  a	
  consequence,	
  an	
  Inline	
  XBRL	
  processor	
  is	
  not	
  aware	
  of	
  the	
  
constraints	
  of	
  the	
  content	
  model	
  of	
  a	
  Taxonomy	
  tuple	
  definition.	
  It	
  is	
  therefore	
  up	
  to	
  the	
  
creator	
  of	
  the	
  Inline	
  XBRL	
  mark-­‐up	
  to	
  explicitly	
  provide	
  information	
  about	
  the	
  order	
  in	
  
which	
  tuple	
  members	
  are	
  to	
  appear	
  in	
  the	
  target	
  XBRL	
  instance	
  document	
  (the	
  order	
  of	
  
tuples	
  themselves	
  and	
  other	
  primary	
  items	
  is,	
  of	
  course,	
  irrelevant).	
  
	
  
The	
  ‘order’	
  attribute	
  exists	
  to	
  carry	
  this	
  information	
  and	
  it	
  can	
  take	
  any	
  decimal	
  value.	
  
The	
  output	
  order	
  of	
  tuple	
  members	
  is	
  imposed	
  by	
  the	
  natural	
  ordering	
  relation	
  defined	
  
by	
  decimal	
  values	
  of	
  increasing	
  magnitude	
  -­‐	
  it	
  is	
  not	
  necessary	
  for	
  the	
  values	
  to	
  be	
  
consecutive	
  integers.	
  This	
  allows	
  an	
  application	
  to	
  assign	
  static	
  order	
  values	
  to	
  each	
  
member	
  of	
  a	
  tuple,	
  corresponding	
  with	
  the	
  order	
  defined	
  by	
  the	
  ComplexType	
  definition	
  
in	
  a	
  Taxonomy,	
  regardless	
  of	
  whether	
  every	
  tuple	
  member	
  appears	
  in	
  the	
  output.	
  
	
  
The	
  fractional	
  part	
  of	
  the	
  decimal	
  value	
  can	
  be	
  used	
  to	
  represent	
  the	
  order	
  of	
  members	
  
in	
  a	
  tuple	
  nested	
  inside	
  another	
  tuple.	
  	
  For	
  example,	
  if	
  a	
  tuple	
  were	
  the	
  4th	
  child	
  member	
  
of	
  an	
  enclosing	
  tuple	
  its	
  member	
  content	
  could	
  be	
  ordered	
  thus:	
  4.1,	
  4.2,	
  4.3,	
  etc	
  –	
  in	
  
terms	
  of	
  the	
  sub-­‐tuple	
  the	
  constant	
  integer	
  part	
  is	
  irrelevant;	
  the	
  ordering	
  of	
  members	
  is	
  
defined	
  by	
  the	
  fractional	
  part.	
  
	
  

4.9	
  

Marking	
  up	
  Boolean	
  items	
  

There	
  are	
  a	
  number	
  of	
  Boolean-­‐type	
  concepts	
  in	
  the	
  UK	
  Accounts	
  Taxonomies	
  that	
  
correspond	
  to	
  statements	
  that	
  by	
  convention	
  appear	
  on	
  the	
  face	
  of	
  Accounts:	
  claims	
  for	
  
exemptions	
  (from	
  the	
  need	
  for	
  an	
  audit	
  for	
  instance),	
  statements	
  of	
  fact	
  (“the	
  company	
  
is	
  trading”),	
  etc.	
  Aligning	
  the	
  mark-­‐up	
  of	
  these	
  statements	
  with	
  the	
  value	
  that	
  is	
  to	
  
appear	
  in	
  the	
  target	
  XBRL	
  instance	
  (i.e.	
  “true”	
  or	
  “false”)	
  can	
  be	
  problematic,	
  especially	
  
for	
  conversion	
  or	
  manual	
  tagging	
  tools.	
  
	
  
A	
  medium-­‐term	
  solution	
  to	
  this	
  is	
  in	
  the	
  process	
  of	
  being	
  standardised	
  by	
  the	
  XII	
  
Rendering	
  Working	
  Group	
  in	
  the	
  form	
  of	
  a	
  pair	
  of	
  Transformation	
  Rules	
  Registry	
  
transforms	
  called	
  ixt:booleantrue	
  and	
  ixt:booleanfalse,	
  but	
  these	
  will	
  not	
  be	
  available	
  in	
  
the	
  CT	
  online	
  service	
  for	
  some	
  time.	
  The	
  intention	
  of	
  these	
  transforms	
  is	
  to	
  allow	
  some	
  
Page	
  15	
  of	
  20	
  
	
  

v1.4	
  –	
  February	
  2011	
  
	
  
arbitrary	
  text	
  (the	
  true/false	
  statement)	
  to	
  be	
  marked-­‐up	
  as	
  normal,	
  but	
  for	
  the	
  text	
  to	
  
be	
  transformed	
  to	
  either	
  “true”	
  or	
  “false”	
  in	
  the	
  target	
  XBRL	
  instance,	
  depending	
  on	
  
which	
  transform	
  is	
  applied.	
  This	
  should	
  allow	
  such	
  mark-­‐up	
  to	
  be	
  undertaken	
  in	
  the	
  
same	
  way	
  as	
  any	
  other	
  value	
  that	
  might	
  require	
  a	
  transform,	
  and	
  avoid	
  special-­‐purpose	
  
code	
  in	
  tagging	
  tools	
  designed	
  only	
  to	
  handle	
  Boolean	
  items.	
  
	
  
In	
  the	
  meantime,	
  the	
  ix:exclude	
  element	
  can	
  be	
  used	
  to	
  simulate	
  this	
  behaviour	
  at	
  the	
  
cost	
  of	
  a	
  little	
  additional	
  complexity	
  in	
  the	
  mark-­‐up	
  (which	
  nevertheless	
  follows	
  a	
  
pattern	
  that	
  applications	
  can	
  easily	
  apply).	
  	
  
	
  
If	
  we	
  assume	
  that	
  the	
  sentence	
  “The	
  company	
  is	
  trading.”	
  appears	
  on	
  the	
  face	
  of	
  the	
  
Accounts	
  then	
  the	
  following	
  “pattern”	
  will	
  allow	
  the	
  Inline	
  XBRL	
  mark-­‐up	
  of	
  this	
  text	
  
with	
  a	
  Boolean	
  item	
  such	
  as	
  uk-­‐bus:EntityTrading:	
  
	
  

The company is trading.
true


	
  
The	
  nested	
  ix:exclude	
  element	
  allows	
  part	
  of	
  the	
  content	
  within	
  the	
  ix:nonNumeric	
  
element	
  (the	
  statement	
  itself)	
  to	
  be	
  excluded	
  from	
  the	
  item	
  in	
  the	
  target	
  XBRL	
  instance	
  
document,	
  whilst	
  the	
  CSS	
  style	
  on	
  the	
  div	
  element	
  suppresses	
  display	
  of	
  the	
  actual	
  
Boolean	
  value	
  on	
  the	
  face	
  of	
  the	
  document,	
  which	
  is	
  the	
  part	
  of	
  the	
  marked-­‐up	
  value	
  that	
  
is	
  carried	
  into	
  the	
  target	
  XBRL.	
  At	
  the	
  same	
  time,	
  visible	
  correspondence	
  between	
  the	
  
marked-­‐up	
  statement	
  and	
  the	
  resulting	
  data	
  value	
  is	
  maintained,	
  improving	
  document	
  
assurance.	
  
	
  
In	
  time,	
  this	
  pattern	
  can	
  be	
  substituted	
  by	
  a	
  simpler	
  one	
  that	
  uses	
  the	
  ixt:booleantrue	
  
format	
  transform	
  (when	
  it	
  is	
  available)	
  on	
  the	
  ix:nonNumeric	
  element	
  and	
  does	
  away	
  
with	
  the	
  need	
  for	
  any	
  nested	
  mark-­‐up.	
  
	
  

4.10	
   Marking	
  up	
  empty	
  “flag”	
  items	
  
There	
  are	
  a	
  handful	
  of	
  concepts	
  (of	
  type	
  fixedItemType)	
  in	
  the	
  UK	
  Accounts	
  Taxonomies	
  
whose	
  presence	
  in	
  the	
  target	
  XBRL	
  instance	
  document	
  is	
  sufficient	
  to	
  convey	
  a	
  piece	
  of	
  
information	
  (hence	
  the	
  term	
  “flag”)	
  –	
  no	
  value	
  is	
  necessary;	
  in	
  fact	
  no	
  value	
  is	
  allowed.	
  A	
  
prime	
  example	
  is	
  uk-­‐bus:DirectorSigningReport,	
  which	
  associates	
  the	
  signing	
  of	
  the	
  
Accounts	
  with	
  a	
  particular	
  Director	
  via	
  a	
  specific	
  member	
  of	
  the	
  EntityOfficers	
  
dimension	
  in	
  the	
  context	
  of	
  the	
  item.	
  Aligning	
  the	
  mark-­‐up	
  of	
  these	
  items	
  in	
  the	
  target	
  
XBRL	
  instance	
  document	
  with	
  facts	
  reported	
  on	
  the	
  face	
  of	
  the	
  Accounts	
  can	
  be	
  
problematic,	
  especially	
  for	
  conversion	
  or	
  manual	
  tagging	
  tools.	
  
	
  
A	
  medium-­‐term	
  solution	
  to	
  this	
  is	
  in	
  the	
  process	
  of	
  being	
  standardised	
  by	
  the	
  XII	
  
Rendering	
  Working	
  Group	
  in	
  the	
  form	
  of	
  a	
  Transformation	
  Rules	
  Registry	
  transform	
  
called	
  ixt:nocontent,	
  but	
  this	
  will	
  not	
  be	
  available	
  in	
  the	
  CT	
  online	
  service	
  for	
  some	
  time.	
  
The	
  intention	
  of	
  this	
  transform	
  is	
  to	
  allow	
  some	
  arbitrary	
  text	
  (e.g.	
  the	
  name	
  of	
  the	
  
Director	
  signing	
  the	
  Accounts)	
  to	
  be	
  marked-­‐up	
  as	
  normal,	
  but	
  for	
  the	
  text	
  to	
  be	
  
transformed	
  to	
  an	
  empty	
  element	
  (associated	
  with	
  an	
  appropriate	
  context)	
  in	
  the	
  target	
  
XBRL	
  instance.	
  This	
  should	
  allow	
  such	
  mark-­‐up	
  to	
  be	
  undertaken	
  in	
  the	
  same	
  way	
  as	
  any	
  
other	
  value	
  that	
  might	
  require	
  a	
  transform,	
  and	
  avoid	
  special-­‐purpose	
  code	
  in	
  tagging	
  
tools	
  designed	
  only	
  to	
  handle	
  “flag”	
  items.	
  
	
  

Page	
  16	
  of	
  20	
  
	
  

v1.4	
  –	
  February	
  2011	
  
	
  
In	
  the	
  meantime,	
  the	
  ix:exclude	
  element	
  can	
  be	
  used	
  to	
  simulate	
  this	
  behaviour	
  at	
  the	
  
cost	
  of	
  a	
  little	
  additional	
  complexity	
  in	
  the	
  mark-­‐up	
  (which	
  nevertheless	
  follows	
  a	
  
pattern	
  that	
  applications	
  can	
  easily	
  apply).	
  
	
  
If	
  we	
  assume	
  that	
  the	
  name	
  “Joe	
  Bloggs”	
  appears	
  on	
  the	
  face	
  of	
  the	
  Accounts	
  as	
  the	
  
Director	
  signing	
  the	
  Accounts	
  then	
  the	
  following	
  “pattern”	
  will	
  allow	
  the	
  Inline	
  XBRL	
  
mark-­‐up	
  of	
  this	
  text	
  with	
  a	
  “flag”	
  item	
  such	
  as	
  uk-­‐bus:DirectorSigningReport:	
  
	
  
Joe Bloggs

	
  
The	
  nested	
  ix:exclude	
  element4	
  results	
  in	
  the	
  total	
  exclusion	
  of	
  the	
  Director’s	
  name	
  from	
  
the	
  item	
  in	
  the	
  target	
  XBRL	
  instance	
  document.	
  At	
  the	
  same	
  time,	
  visible	
  
correspondence	
  between	
  the	
  marked-­‐up	
  name	
  and	
  the	
  resulting	
  “flag”	
  item	
  is	
  
maintained,	
  improving	
  document	
  assurance.	
  
	
  
In	
  time,	
  this	
  pattern	
  can	
  be	
  substituted	
  by	
  a	
  simpler	
  one	
  that	
  uses	
  the	
  ixt:nocontent	
  
format	
  transform	
  (when	
  it	
  is	
  available)	
  on	
  the	
  ix:nonNumeric	
  element	
  and	
  does	
  away	
  
with	
  the	
  need	
  for	
  any	
  nested	
  mark-­‐up.	
  
	
  
	
  
	
  
	
  

	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  
4	
  Note:	
  unlike	
  the	
  similar	
  pattern	
  for	
  the	
  mark-­‐up	
  of	
  Boolean	
  items	
  (see	
  §	
  4.9)	
  it	
  is	
  not	
  possible	
  in	
  this	
  case	
  
to	
  add	
  any	
  whitespace	
  (including	
  line	
  breaks)	
  within	
  ix:nonNumeric	
  but	
  outside	
  ix:exclude	
  –	
  the	
  
fixedItemType	
  of	
  uk-­‐bus:DirectorSigningReport	
  preserves	
  whitespace	
  in	
  the	
  element	
  content	
  and	
  any	
  
residual	
  whitespace	
  violates	
  the	
  maxLength	
  facet,	
  which	
  for	
  fixedItemType	
  is	
  zero.	
  

	
  

Page	
  17	
  of	
  20	
  
	
  

v1.4	
  –	
  February	
  2011	
  
	
  

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	
  tagging	
  requirements	
  for	
  the	
  Accounts	
  Taxonomies	
  are	
  as	
  follows:	
  
	
  
Taxonomy	
  
Full	
  List	
  of	
  Concepts	
   Minimum	
  Tagging	
  Reqmt	
  
UK	
  GAAP	
  2008	
  
UK	
  GAAP	
  2009	
  
UK	
  IFRS	
  2009	
  

4,375	
  
5,242	
  
3,805	
  

1,182	
  
1,257	
  
1,634	
  

	
  
The	
  companion	
  Common	
  Data	
  Taxonomy	
  (which	
  is	
  actually	
  a	
  component	
  part	
  of	
  the	
  
2009	
  Accounts	
  Taxonomies),	
  which	
  contains	
  972	
  concept	
  and	
  domain	
  member	
  
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:	
  
Page	
  18	
  of	
  20	
  
	
  

v1.4	
  –	
  February	
  2011	
  
	
  
	
  


12345678





2007-04-01
2008-03-31



	
  
Note	
  that	
  the	
  scheme	
  URI	
  should	
  appear	
  with5	
  a	
  trailing	
  ‘/’	
  –	
  this	
  is	
  simply	
  a	
  convention	
  
that	
  we	
  have	
  chosen	
  to	
  adopt	
  and	
  agreed	
  with	
  both	
  XBRL	
  UK	
  and	
  Companies	
  House.	
  It	
  is	
  
important	
  to	
  settle	
  on	
  a	
  single	
  form	
  for	
  the	
  scheme	
  because	
  all	
  the	
  characters	
  of	
  the	
  URI	
  
are	
  significant	
  –	
  variants	
  with	
  or	
  without	
  the	
  trailing	
  ‘/’	
  are,	
  strictly	
  speaking,	
  different	
  
schemes.	
  
	
  
The	
  variant	
  with	
  the	
  trailing	
  slash	
  is	
  the	
  normalised	
  form	
  according	
  to	
  IETF	
  RFC	
  3986	
  –	
  
URI	
  Generic	
  Syntax6.	
  

	
  

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	
  difficulties7.	
  
	
  
To	
  enable	
  SDS	
  Team	
  to	
  provide	
  meaningful	
  statistics	
  to	
  vendors	
  of	
  standalone	
  Accounts	
  
production	
  software	
  packages	
  we	
  recommend	
  that	
  product	
  and	
  version	
  information	
  is	
  
embedded	
  in	
  the	
  generated	
  Inline	
  XBRL	
  document	
  using	
  the	
  document	
  metadata	
  tags	
  
from	
  the	
  Common	
  Data	
  Taxonomy	
  or	
  Common	
  Data	
  module	
  (vendor	
  web	
  site	
  URL	
  is	
  not	
  
necessary).	
  
	
  
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.	
  
(omitting	
  context	
  refs,	
  etc	
  for	
  clarity):	
  



Acme Accounts v1.1

	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  
5	
  Please	
  note	
  that	
  this	
  is	
  a	
  reversal	
  from	
  previous	
  versions	
  of	
  this	
  document.	
  
6	
  Section	
  6.2.3,	
  Scheme-­‐based	
  Normalisation,	
  http://www.ietf.org/rfc/rfc3986.txt	
  
7	
  Separate	
  Tax	
  Computation	
  preparation	
  software	
  packages	
  are	
  unlikely	
  –	
  this	
  function	
  is	
  usually	
  closely	
  
associated	
  with	
  the	
  filing	
  application	
  that	
  creates	
  and	
  submits	
  the	
  CT600	
  XML	
  document.	
  

Page	
  19	
  of	
  20	
  
	
  

v1.4	
  –	
  February	
  2011	
  
	
  




	
  	
  
	
  
The	
  Inline	
  XBRL	
  equivalent	
  of	
  this	
  XBRL	
  fragment	
  (using	
  ix:tuple,	
  and	
  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.	
  
	
  
The	
  structure	
  of	
  the	
  2009	
  Common	
  Data	
  module	
  (incorporated	
  in	
  the	
  2009	
  UK	
  GAAP	
  
and	
  UK	
  IFRS	
  Taxonomies)	
  has	
  changed	
  somewhat.	
  In	
  this	
  case	
  we	
  recommend	
  using	
  the	
  
single	
  XBRLDocumentAuthorGrouping	
  tuple,	
  identifying	
  the	
  author	
  as	
  a	
  software	
  
package	
  with	
  the	
  value	
  “Software”	
  in	
  the	
  ‘Description	
  or	
  Title	
  of	
  Author’	
  tag:	
  

Acme Accounts v1.1
Software


When	
  seeking	
  recognition	
  for	
  Accounts	
  production	
  products	
  it	
  is	
  important	
  that	
  
software	
  developers	
  use	
  the	
  product	
  name	
  string	
  in	
  NameAuthor	
  that	
  they	
  intend	
  to	
  
embed	
  in	
  live	
  submissions	
  so	
  that	
  SDS	
  Team	
  can	
  identify	
  product	
  names,	
  associate	
  them	
  
with	
  product	
  vendors	
  and	
  provide	
  meaningful	
  statistics	
  in	
  their	
  feedback.	
  
	
  

5.4	
  

The	
  Proper	
  Use	
  of	
  Tuples	
  

The	
  primary	
  purpose	
  of	
  a	
  tuple	
  in	
  XBRL	
  is	
  to	
  bind	
  a	
  collection	
  of	
  related	
  facts	
  together	
  
and	
  provide	
  a	
  mechanism	
  for	
  repeated	
  occurrences	
  of	
  that	
  collection,	
  much	
  like	
  a	
  table	
  
with	
  multiple	
  columns	
  and	
  one	
  or	
  more	
  rows.	
  However,	
  in	
  XBRL	
  terms,	
  the	
  concepts	
  
that	
  are	
  intended	
  to	
  be	
  bound	
  together	
  in	
  a	
  tuple	
  rank	
  equally	
  with	
  concepts	
  that	
  are	
  
used	
  outside	
  of	
  tuples,	
  which	
  means	
  that	
  it	
  is	
  permitted	
  (by	
  the	
  XBRL	
  Specification)	
  to	
  
use	
  these	
  concepts	
  to	
  represent	
  facts	
  outside	
  of	
  any	
  tuple	
  structure.	
  
	
  
The	
  temptation,	
  therefore,	
  when	
  only	
  one	
  collection	
  of	
  facts	
  is	
  required	
  (i.e.	
  a	
  “table”	
  
with	
  only	
  one	
  “row”)	
  is	
  to	
  omit	
  the	
  tuple	
  “container”	
  and	
  simply	
  mark-­‐up	
  the	
  individual	
  
facts.	
  This	
  is	
  then	
  carried	
  through	
  to	
  the	
  Inline	
  XBRL	
  mark-­‐up	
  where	
  the	
  corresponding	
  
ix:tuple	
  element	
  is	
  omitted,	
  along	
  with	
  the	
  order	
  and	
  tupleRef	
  attributes	
  on	
  the	
  member	
  
facts.	
  Such	
  behaviour	
  by	
  applications	
  that	
  generate	
  Inline	
  XBRL	
  is	
  strongly	
  discouraged.	
  
When	
  a	
  tuple	
  is	
  expected	
  it	
  should	
  be	
  used	
  even	
  if,	
  in	
  terms	
  of	
  distinguishing	
  between	
  
multiple	
  collections	
  of	
  facts,	
  it	
  is	
  redundant.	
  This	
  should	
  simplify	
  both	
  generating	
  and	
  
consuming	
  applications	
  and	
  avoid	
  complications	
  with	
  analysis	
  applications	
  that	
  expect	
  
to	
  see	
  certain	
  facts	
  inside	
  tuples	
  regardless	
  of	
  their	
  cardinality.	
  

Page	
  20	
  of	
  20	
  
	
  



---

Source Exif Data:

File Type                       : PDF
File Type Extension             : pdf
MIME Type                       : application/pdf
PDF Version                     : 1.3
Linearized                      : No
XMP Toolkit                     : 3.1-702
Create Date                     : 2011:02:14 12:37:10Z
Creator Tool                    : Microsoft Word
Modify Date                     : 2011:02:14 12:46:31Z
Metadata Date                   : 2011:02:14 12:46:31Z
Format                          : application/pdf
Description                     : HMRC Inline XBRL Style Guide v1.4
Creator                         : HMRC
Title                           : HMRC Inline XBRL Style Guide v1.4
Producer                        : Mac OS X 10.6.6 Quartz PDFContext
Document ID                     : uuid:0659e489-3383-4549-97c9-e6740a5021b1
Instance ID                     : uuid:dab3a5d1-93c8-4607-a751-facf7f870584
Page Count                      : 20
Subject                         : HMRC Inline XBRL Style Guide v1.4
Author                          : HMRC
Warning                         : [Minor] Ignored duplicate Info dictionary

EXIF Metadata provided by EXIF.tools