From XBRL

Contents 1 e-mail from David Forbes and response from Philip Allen 1.1 further follow up on this e-mail thread 2 Comments from the IASCF XBRL team (Olivier Servais) 3 e-mail from Ian Stokes-Rees and comments from Philip Allen 4 e-mail from Geoff Shuetrim and response from Philip Allen

e-mail from David Forbes and response from Philip Allen

On Tuesday 19 February 2008 10:48, dave@forbes.co.uk wrote:
> I don't see how the proposed inline xbrl allows "roundtripping" of data.
> In the more conventional approach human readable data is used to
> produce XBRL. If this XBRL can then be independently rendered back to
> a human readable form this can be compared with the original to ensure fidelity.
> I feel also that inline XBRL, or any scheme which transmits both the
> XBRL and rendering opens the doors to inconsistencies.

Inline XBRL is not designed for round-tripping. Rather, it is designed to be a solution that will work for all classes of document, one that will work where the "manual round-tripping" approach you describe above will not work. For instance - if you have extended the taxonomy in order to create the XBRL document, it is quite likely that the rendering mechanism will *not* be able to display the output in a way that will match the original "human readable" format.

You may consider that the match will still be "good enough" - but that is the (cultural ?) issue which we have to deal with. For small companies, filing XBRL accounts is a matter of regulatory compliance. For large companies (and my firm has considerable experience of preparing rendered XBRL for Fortune 100 companies) the consideration of "what is good enough"
is very much more constrained. It would be nice if they would accept a rough similarity... but there's not much sign of that at the moment.

So, philosophically, what I would ask you to bear in mind is that there are a number of very different use cases in the XBRL world. Stylesheeted rendering is working very well for filings at Companies House, but it won't work for FTSE companies (any more than it will work for Fortune 1000 companies). Inline XBRL is not intended to exclude other methods of rendering XBRL.

> Ignoring the major philosophical objections on a practical note I have
> a number of queries :-
>
> 1. what to do when the same XBRL fact appears in multiple places in
> the formatted accounts.

The duplicate facts are to be put into the ix:hidden element.

> 2. what to do when the same figure appearing just once due to removal
> of redundant subtotals needs to generate several (obviously equal
> valued !) XBRL facts.

Is this resolved by the answer to [1] above ?

> 3. granularity issues - multiple XBRL facts totalled to a single value
> in the formatted accounts

So far as the Specification is concerned, the non-displayed XBRL facts would be placed in ix:hidden. However, it may be that regulators (such as
HMRC) will deprecate the hiding of XBRL facts which are not duplicates.

Of course, your ability to decide which facts appear and which don't is already very much constrained if you use the stylesheet mechanism. As I understand it, the stylesheet will throw a warning if unknown elements are included. We might expect HMRC similarly to be warned about hidden elements in the inline XBRL.

> 4. granularity issues - multiple values in the formatted accounts
> mapped (with or without a subtotal) to a single XBRL fact.

There is nothing in the Specification to stop you doing this, although it is doubtful if any "mapping" would be apparent. It's worth noting that this would not be possible in any shape or form using a stylesheet.

> 5. granularity issues - mismatch in compound elements - e.g. £700,£300
> in formatted accounts £600,£400 in XBRL elements.

Do you have an example of this ?

> 6. display format issues - user defined date formats, numeric and
> rounding (e.g. display = "£(30)" xbrl== -30000)

In general, non-numeric elements are kept *outside* the ix: tags, so you might have:

<b>£(<ix:nonNumeric ...>30</ix:nonNumeric>)</b>

We would use the ix:scale and ix:format attributes to handle obvious and non-obvious format mappings between the iXBRL and XBRL documents.

> And finally .... though conceptually simple, (once 1...6 above is
> sorted) I think it would be unwise to underestimate the difficulty of
> automating the "marking up" of existing legacy formats (ignoring the
> issue of converting them to html and the intellectual property
> ramifications of doing so). For example - what do you do when where
> purely syntactic matching is not possible, e.g. when you have a line
> that just says "=SubTotal()" - working out what XBRL element it
> should map to ?

I have always believed that the mapping aspect of XBRL filing is the key, and most difficult, part of the process (and you, having done it yourself, will no doubt have a view on this). But surely the example you give is similarly difficult whether using conventional or inline XBRL ?

> David Forbes
>
> Forbes Computer Systems Ltd
> Guise House, Church St, Aspley Guise, MK17 8HQ Registered in England
> No. 2829879

further follow up on this e-mail thread

On Friday 22 February 2008 13:40, dave@tax.co.uk wrote:
>
> I have talked informally to the 3 FTSE100 CEOs that live in or around
> Aspley Guise and they would favour a completely separate pdf and XBRL
> instance data transmission. As for the other 97 who knows.

The problem is that HMRC only wants the data, the XBRL: they don't want a second version. Having two completely separate documents (one to process, one to view) doesn't make sense because it is completely impossible to check that one reflects the other. Over time, much of the analysis of returns will depend on data-processing rather than document-eyeballing.

> From talking to a number of accountants the approach would be
>
> A. produce the xbrl instance
> B. style it with the HMRC stylesheet
> C. If happy with the output all they send is the instance.
> D. In the odd occasions that the xbrl does not match to the
> satisfaction of the accountant then send a pdf.

This is a question of what HMRC are prepared to accept.

> The fact there are items that could not be rendered satisfactorily in
> the stylesheet is why there is a pdf "escape" mechanism.
>
> All the points mentioned came up in practice when trying to mark up a
> real set of accounts in XBRL.
>
> 1. Will not having the same XBRL element, even if hidden, appearing
> more than once, cause problems producing an invalid instance or is
> this taken care of by the extraction xslt ?

There is no prohibition on duplicate XBRL Facts in the XBRL Specification.

> 2,3. I do not like the sound of hidden elements - what if they contain
> an error ? What if the HMRC deprecate them ?

Depending on the error, it may be picked up when the XBRL is extracted and validated. HMRC won't deprecate all hidden elements - it might have certain items it expected to be hidden (the CH AE filings, for instance, include certain XBRL Facts which are not rendererd) and other items (like repeated facts as in the example in the Spec.) would be acceptable. I would expect HMRC to test the hidden elements and show the tax inspector a report of items that didn't seem to have a good reason for not being displayed.

> 4. I don't understand your answer. Say in the formatted accounts it
> says
>
> Cash in hand 500
> Cash at bank 300
>
> These need to go into a single xbrl element cashatbankandinhand. How
> is this to be done ?

This is quite a good use case for ix:hidden. The two cashes are untagged but displayed, and the single XBRL element goes into ix:hidden.

> 5. in accounts say the break down is different from the XBRL. Without
> having seen the detailed P&L elements I will manufacture an example :-
>
> Ground rent and insurance 700
> Other Rents, rates 300
>
> in the xbrl:
>
> rentsratesinurance 500
> groundrent 500

This isn't really an iXBRL problem. It's more a general XBRL mapping issue. The groupings *should* map into UK GAAP. Alternatively, you could create the top two as elements in an extension taxonomy.

> 6. things like showing negatives as amounts in brackets will be ok,
> showing 30,000 as 30 will be ok ?

Yes. Here's an example:

iXBRL:

(<ix:nonFraction name="foo" sign="-" scale="3">30</ix:nonFraction>)

XBRL:

<foo>-30000</foo>

> 7. producing the mapping is relatively straight forward. marking up
> the formats is (I admit being suprised too) actually quite difficult -
> and ours already in xhtml. I am happy from someone from DS to come
> over and see the details and guide us through.
>
> To put it into non-proprietry talk - imagine we have lots of xml
> instances in our format out there, styled using stylesheets some
> produced by us, some by our customers, to produce html. Problem one -
> producing xbrl instances is the problem of taking our instances and
> converting them to xbrl instances - achievable using a stylesheet.
> Problem 2 of "going inline" is trying to find an automated way of
> editing all those stylesheets that produce the final accounts to
> produce the inline xbrl as well, remembering of course that we did not
> produce them. Not so easy !
>
> David

Comments from the IASCF XBRL team (Olivier Servais)

The IASC Foundation XBRL Team conducted a review of the PWD for Inline XBRL 0.54. Due to the character of the specification (standards for embedding XBRL fragments into an HTML document) this is not directly applying to the IFRS taxonomy developments efforts (while the second stream of the Rendering Working Group concerning rendering linkbase seems much more interesting).

IASC Foundation XBRL Team being observer of the Rendering Working Group efforts would like only to provide some hints and raise minor questions about the PWD. This is mainly due to lack of deep technical involvement in the creation of the PWD and lack of use cases created by the XBRL Team which could be used to in-depth test the PWD.

First point refers to general understanding of the role of Inline XBRL in financial reporting supply chain. The "traditional" understanding of taxonomy mapping to the ERP/ data base or DWH than generation of instance document and its validation and first than rendering seems to be changed with the use of Inline XBRL. The creation of documents which can be viewed in a browser (while making automatic processing of the facts generation possible) needs to be considered in the context of the IFRS reporting supply chain and the reasoning behind taxonomy architectures being DWH complaint (or browser/rendering compliant). We would welcome more extensive explanation of the business case in the 1. Introduction section.

Second point we would like to raise is the support for dimensional contexts. While we see possibility of introducing it with 9.2.2 Attributes we would welcome brief clarification on this point.

Further the definition of the 9.2.1 Element name is questionable for us in regards to prefix usage in the attribute value. Due to the fact that namespace prefix itself is not meaningful we consider if it will not lead to confusion of namespace URI will be not defined or if a number of instance documents should be created.

Please consider all our questions and hints as indication only due to lower importance of Inline XBRL for direct IFRS taxonomy development.

e-mail from Ian Stokes-Rees and comments from Philip Allen

On Monday 18 February 2008 06:43, Ian Stokes-Rees wrote:
>
> * I would consider re-ordering the IX element definitions into an
> order which makes sense for reading, rather than alphabetical.

No, because if the contents don't read alphabetically it is impossible to find anything.

> * I would consider adding hyperlinks for IX element names to take the
> reader to the definition.

Yes, will look into this (low priority).

> * There is a semi-formal "Abstract Module Definition" format advocated
> by the XHTML modularization specification here:

http://www.w3.org/TR/2006/WD-xhtml-modularization-20060705/xhtml-modularization.html#s_abstraction

> It suggests using ?,*,+,&,| with the usual definitions. I would
> suggest this could be useful for the content model definitions in the
> IX specification.

We are looking at generating this automatically from the schema - like the W3C does.

> * I think there are many places where the term "children" should
> probably be replaced with "descendant", in the cases where there may
> be intervening mark-up elements.

But not everywhere. I have made a number of changes which *should* correct this.

> * Can "ix:exclude" contain other ix:* elements? What about
> specifically ix:nonNumeric or ix:exclude inside ix:exclude? What
> about mixed content? The schema does not put any constraints on it.
> It is conceivable that ix:exclude could be limited via XSD to only be
> a descendant of ix:nonNumeric, but it would require,to the best of my
> knowledge, replicating the content model definitions for all standard
> XHTML elements to have a version which allowed ix:exclude, and to
> *only* recursively refer to this content model when "inside" ix:nonNumeric.
> This seems like way too much work and confusion (since the same
> probably comes up in other places), and is a constraint which should
> be asserted outside the XSD (e.g. Schematron).

Good point. For clarity, I will forbid any ix: elements inside ix:exclude.

> * ix:footnoteLink: the comment about other language versions being
> placed in ix:hidden doesn't seem to answer the problem of how would
> these "duplicate" ix:footnoteLink elements be associated with the
> "originals"? Same ID couldn't be used (these need to be unique). I
> would keep this issue flagged as a possible problem for IX.

Hmm. I'll look at this later on.

> * ix:header: the recommendations regarding head, div, style,
> display:none are all XHTML specific comments. Is there a motivation
> for saying that it should not be in the "head" section?

Yes. If you put it in "head" the DOM may not be able to see it, in most browsers.

> It is true to say that if div or style are used *external* to the
> ix:header section, then that implies it *must* be in the <body>
> section of the XHTML document. The current wording suggests it would
> be OK to place *inside* <html> but *outside* <body> (e.g. either before or after.

I don't think we have a reason to be specific about the location except the DOM problem in <head>. The <div> issue is only a RECOMMENDATION because there could be in time other equally satisfactory ways to hide the display.

> * The content model for ix:header should be (ix:hidden? | ix:resources?
>
> | ix:references+) unless the spec content model cardinality for
>
> ix:header is commutative and additive with the body text (which is to
> say, the "+" is applied to ix:hidden and ix:resources), in which case
> the combination of this content model (+ = at least one of each is
> required) with the text stating no more than one is allowed results in
> the requirement for *exactly* one ix:hidden and ix:resources. In the
> schema, I assume something different yet again, which is (ix:hidden? |
> ix:resources? | ix:references*) since I don't understand why
> ix:references would *always* be required. Furthermore, within
> ix:header elements must appear in the order ix:hidden, ix:references,
> ix:resources (due to a limitation of how one writes XML Schema).

I think you have misread the spec: in particular, the distinction between Document cardinality and Document Set cardinality. ix:references is [+] with regard to the iXBRL Document Set. The model in the spec -

( ix:hidden | ix:references | ix:resources) +

although not able to encompass all the relevant rules, is correct.

> * ix:target: I don't see why this should be listed as an NCName. The
> names of target documents don't have a lot to do with the lexical
> constraints on XML element names or type definitions. The effect of
> this is that the target document could not have "/" in it, limited
> punctuation, no spaces, etc. Is this really intended? Even if it is,
> a proper definition of what is a legal target document name with an
> associated appropriate XML Schema would be preferable.

Good point. I'll change it back to string.

> * ix:hidden: to confirm content model: at least one of the 5 elements
> must be present. It is not legal to have ix:hidden empty. This is
> how the schema is now defined.

Correct.

> * ix:references/@ix:target: should be marked as optional (?) in the
> content model since text suggests this is possible (can be interpreted
> from default value if not present), however content model suggests it
> is mandatory (unless reader is meant to infer that attributes are, by
> default, optional, as they are in XML Schema, in the absence of
> cardinality symbols in the content model definition).

OK. We may not have properly tied down the format of the Representation
Summaries: something for later. But yes, ix:target is optional. This applies to all places where it is allowed.

> * Some of the example IX shows unqualified attributes. Attributes are
> either explicitly prefixed if in a namespace, or have no prefix if
> they are in the null namespace. The spec suggests that all attributes
> are namespaced, and if this is true then they must *always* be
> prefixed in IX. I am assuming they are qualified and will add the prefix.
> BACKTRACK: I am trying to do minimal modifications to the existing
> XBRL schemas, for obvious reasons. The existing XBRL schemas *do not*
> use qualified attributes for xbrli:contextRef or xbrli:unitRef. As
> such, the IX spec should not suggest (as it currently does) that the
> attributes contextRef or unitRef are inside the xbrli namespace (they
> are not). For these external attributes, I will assume at the very
> least the spec will change to refer to the null namespace version of
> the attributes, however I will leave the other attributes qualified
> until I know what decision is going to be made regarding this.

Sorry, you're quite right. The null namespace is used for contextRef, unitRef, decimals and precision. I have changed the spec accordingly.

> * ix:numerator/denominator: as for ix:exclude, there is no good XML
> Schema way to redefine the content model of *all* non-ix elements to
> allow them to have ix:numerator/denominator as child content. As
> such, I am simply adding ix:numerator/denominator to the
> xhtml.Flow.mix class of elements and *other* constraints will need to
> be applied to make sure these elements are, in fact, legally placed.

Agreed.

> *ix:numerator/denominator: These are not well defined. What is a
> valid content model for them? Mixed content? Other ix:* elements?
> Should these not be added to the list of "Inline XBRL Elements"
> (section 3.1, Table 1)?

Yes. This was a mistake. I have now fixed this. The content model will loosely follow ix:nonFraction.

> * ix:footnoteLink: these are currently not permitted inside a tuple.
> Is this correct? If so, this seems surprising to me. I am going to
> guess that this is an error and in the schema I allow footnoteLink inside tuple.

It does seem to be correct. Tuples can only have Items and Tuples inside them - not footnoteLinks.

e-mail from Geoff Shuetrim and response from Philip Allen

On Friday 15 February 2008 21:05, Geoff Shuetrim wrote:
> Philip,
>
> Here are some comments on the inline XBRL spec (some v. minor and some
> more big picture). Note that while I have concentrated on my
> concerns, overall, I did appreciate the drafting of the specification.
> It is very accessible. Please share these comments with the members
> of the rendering WG.
>
> 1. It seems odd to me that the aspects of facts that are captured in
> contexts cannot be connected to the aspects that are presented in the
> XHTML. I can see why it is a more detailed spec that would be
> required but cannot see why it is less useful to establish such connections.

No reason why the spec. shouldn't provide for this, except simplicity. We wanted to keep the spec as simple as it could be while still achieving the main goal.

> 2. The spec starts out referring to mixing HTML and XBRL but then
> quickly moves on to working with XHTML and XBRL.

The spec only refers to HTML. It must be well-formed XML, but this does not actually make it XHTML. If you want the iXBRL to be schema valid, though, you will need to be valid against the XHTML+iXBRL modular schema (which is on its way).

> 3. Why does the spec limit itself to XHTML rather than inlining XBRL
> with any XML grammar that is open enough to take large chunks of
> inline XBRL injected into it?

It limits itself to HTML only because we don't have the time (or
requirement) to look at other XML rendering formats. Also, some of the practical problems (like producing a modular XHTML schema) must be solved first at the specific vocabulary level before looking at the more general case. There is no reason why a de-HTMLised or genericised spec shouldn't be produced in the future, once the present spec has settled down: I would have thought it would be straightforward to make it backwards-compatible.

> 4. I do not really get the underlying return that users might expect
> if they do adopt the specification.
>
> An inline XBRL document has the following properties:
>
> A. It can be viewed in a web browser.
>
> B. It contains an XBRL document.
>
> C. Some of the fact values in the XBRL document are shown in the web
> browser view of the inline document.
>
> In comparison to a rendered version of an XBRL document plus an XBRL
> document all you get is that the fact values in the XBRL document are
> perhaps more probably going to be the same values as those shown in
> the web browser.

It is very easy to display all the data in an XBRL instance using a standardised rendering mechanism. It is *not* at all easy to produce output that meets the quality levels demanded at the top end of the market.

It is much easier for preparers (or their software packages) to generate an agreeable HTML rendering of their document than it is to figure out the rendering and then abstract that into a form that can be re-rendered by one of a whole series of as-yet-unwritten XBRL rendering applications.

THIS is the real use case - that preparers get exactly what *they* want to see, and not what the regulator imposes. In some jurisdictions, this is critical... although, in others, it is not much of an issue.

> We still are not sure that the rendered view of the data is the same
> as the data in the XBRL document unless we look long and hard at the
> inline XBRL information - not something that is any easier than
> looking at the XBRL directly.

It's much easier. Automated testing of an iXBRL document will never be perfect but there's no reason to believe it won't pick up most problems.

> What has the cost of this benefit been? One way to assess that is to
> compare what is involved in producing inline XBRL vs Actual XBRL plus
> a rendering of it.
>
> To produce inline XBRL documents we need:
> 1. A DTS.
> 2. A mapping from our data to the DTS and to the various aspect values
> needed to report our data as XBRL.
> 3. A mapping of our XBRL facts to particular nodes in an XHTML report.
>
> To produce actual XBRL plus a rendering of it, we need:
> 1. The same taxonomy
> 2. The same mapping from our data to the DTS and to the various aspect
> values needed to report our data as XBRL.
> 3. A mapping of our XBRL facts to particular nodes in an XHTML report.
>
> Those costs do not look much different to me. Perhaps the difference
> lies in the ease with which the mapping from XBRL facts to the XHTML
> report structure can be done but I do not see that.

No, there's not much difference. Our point is that if you can produce XHTML output you can also produce iXBRL output. The reason you will want to do that is so the regulator can see the binding between the XBRL Facts and the displayed values. Regulators have a real problem using the XBRL document to drive analysis or tax calculations while *viewing* a separate document which has no connection to the XBRL. *That* is why they want the document combined.

> Maybe the difference lies in just distributing a single document
> instead of an XBRL document and a rendering thereof. However, that
> experiment has already been tested, inserting XBRL into PDF documents.
> that experiment has not seen widespread adoption.

No, because the method used to insert the XBRL into the PDFs was highly proprietary and nobody could figure out how to make it easily accessible (either commercially or technically speaking) to the preparer market.

Also, it scores badly for "openness" when compared with iXBRL, which is at least easy for any XBRL expert to read.

> Perhaps I would see the return on this specification better if I had a
> copy of the requirements you are working to.

There are a set of use cases - which I believe Diane was posting.