Rendering:Inline XBRL Third PWD Feedback
From XBRL
This page is for recording and commenting on feedback received on the Third PWD of the Inline XBRL Specification
E-mail from Geoff Shuetrim
I object to publication of the specification as a Candidate Recommendation. Reasons for my objection are set out below.
1. Ambiguous requirements.
The PWD documentation does not identify the requirements being satisfied by the specification, making the success of the specification in meeting any specific set of requirements impossible to assess. This needs to be addressed before the specification can move to CR status given that approval for CR status requires the Rendering WG to document those requirements that are and are not met by the specification.
Apparently, the specification fulfils some subset of the requirements set out at:
http://www.xbrl.org/technical/requirements/REN-REQ-PWD-2007-07-24.zip
It is not at all clear to me which subset of these requirements are fulfilled. It is also concerning to me that some of the requirements in the draft requirements documentation appear to be at odds with the features of the inline rendering specification.
Comments by Peter Calvert on this feedback
The Inline XBRL specification meets all requirements in the Requirements PWD apart from those related to rendering metadata in a taxonomy, which, more or less by definition, it cannot meet. It handles all the examples.
In other words, Inline XBRL does not fully meet requirements 3.1 and 3.20 (it does not allow taxonomy authors to create, amend and control rendering metadata).
It could perhaps be argued whether Inline XBRL fully meets requirement 3.3 (repeatability and consistency), because of the wording of the definition of consistency in that paragraph. However, my view is that it does definitely meet this requirement in principle and any debate on this is a matter of semantics.
Clearly, Inline XBRL also provides a lot of other features which the Requirements document classed as out-of-scope given the perceived difficulty at the time of meeting them.
In summary, the Spec meets all requirements in the PWD except those relating to the creation and control of rendering metadata at the taxonomy level referred to in requirements 3.1 and 3.20.
Comments by Walter Hamscher on this feedback
Which features appear to be "at odds" with the requirements?
As Peter points out, Inline XBRL provides features (such as requirement 3.15) that were originally out of scope.
Geoff Shuetrim: The introduction of the requirements document concludes with:
"Requirements centre on the content and structure of the displayed data. They do not cover presentational features such as font, colours, graphics, pagination and similar items. These are the province of specialist rendering applications.
The standardised method is intended to allow taxonomy authors and instance creators to provide information on how they want data to be ordered and arranged for display. This rendering metadata will act as an input, alongside other data and metadata from XBRL taxonomies and instances, for applications which consume and render XBRL information."
This indicates that the presentational features that are so comprehensively covered by iXBRL are absolutely not the information required. Rather the requirements address layout of the rendered report. It also indicates that the rendering layout metadata is expected to be applicable to multiple XBRL instances, in that it is expected to also be usable by taxonomy authors. This is not at all a feature of iXBRL. The requirements document flows from this perspective on the rendering problem and trying to motivate iXBRL using those requirements is challenging.
Here is my own analysis of the requirements mismatch.
3.1 Not met: "A standardised rendering method MUST allow both taxonomy authors and instance preparers to create, amend and extend rendering metadata. Taxonomy authors may wish to create a standardised rendering for a typical instance based on a taxonomy. This provides a foundation which instance creators MAY use if they wish. ... Instance creators MUST be able to amend any rendering metadata provided in referenced taxonomies."
3.2 Not met: "A standardised rendering method MUST be able to reproduce completely all facts in an instance, including all data types and footnotes, without loss of data. Among other things, this will enable preparers and consumers of an instance to ensure that a standardised rendering is a complete view of an instance and no other information is included in an instance which is not represented in the rendering. A standardised rendering method MUST NOT add information to a rendering which is not included in the instance, the referenced taxonomies or standardised rendering metadata." (runs into trouble with facts to be rendered twice and with facts that need to be rounded prior to rendering. It also runs into trouble with the hidden information feature of iXBRL. It also runs into trouble with the ability to include markup that is not at all linked to the implicit XBRL instance.)
3.3 "Repeatability and consistency." Sort of met except that in iXBRL with everything that is on display in a browser except the fact value being straight HTML, it has considerably less repeatability than a solution where the rendering metadata was fully separable from the instance. Right now, that separation does not carry across to contexts or taxonomy labels etc.
3.4 "Adaptability and consistency": Met
3.5 Not met: "A standardised rendering method MUST show accurately all facts as defined in an instance. In particular, it MUST accurately display numeric data values in accordance with definitions of number, decimals and precision in an instance document." This runs into trouble with the requirement relating to all facts and in relation to the requirement that decimal and precision information be displayed.
3.6 "Positive and negative signs": Met
3.7 "Grouping and ordering": Not Met "A standardised rendering method MUST enable the organisation of data into rows. It MUST enable the definition of content of a row in terms of any individual element, including a tuple element, and/or contexts, including combinations of contexts. It MUST also enable the grouping and ordering of rows. Grouping will define which rows MUST be displayed together in a single section. It MUST support the definition of sub-sections within sections, to an unlimited level of nesting Ordering will define (a) the ordering of rows within sections and sub-sections and (b) the ordering of sections and sub-sections, to an unlimited level of nesting. The means of delineation between sections or sub-sections is a presentational issue which is application dependent and outside the scope of these requirements. (Typically, this might be done with line spaces and/or indentations, but other approaches are possible.) The method MUST preserve the underlying order of facts in the instance when there is no other ordering metadata provided by the user." While iXBRL does allow facts to be interspersed with various HTML row structures there is no sense in which the definition of the content of each row can be expressed in terms of a concept (individual element I guess), a tuple, or context information. This is a fundamental discrepancy between the requirements and iXBRL. Note also that the requirement indicates that the method MUST preserve the underlying order of facts in the instance when there is no other ordering metadata provided by the user. This last part of the requirement indicates strongly that there is an underlying expectation in the requirements that the rendering metadata relating to grouping and ordering will be separate from the instance and thus applicable to multiple instances.
3.8 "Tables": Not met. See 3.7 discussion.
3.9.1 Not Met: "The method MUST enable taxonomy authors and instances preparers easily and efficiently to select labels from a referenced taxonomy for use in a rendering of an instance. It MUST support the ability to select which label role should be used on particular rows and columns. This MAY be done on the basis of individual data values or on sets of data values. For example, standard labels may be appropriate on some sets of data, terse on some, period-start on some and period-end on others." The ability to link labels in the rendering to labels in a referenced taxonomy is not a feature of iXBRL which expects such associations to the application specific.
3.9.2: Not met: "The method MUST enable an instance author easily and efficiently to amend existing taxonomy labels or create new ones for the purposes of rendering." While iXBRL does allow each instance to completely define its own content, there is no sense in which this is an amendment of an existing taxonomy label or the creation of a new one.
3.9.3 "Identification of contexts": Met except for the requirement that taxonomy authors be able to define default row or column headings based on context information
3.9.4 "Construction of identifying labels" Met but not in a manner that seems aligned to the intent of the requirement. The requirement is in terms that seem to imply that the labels in rendering metadata are to be populated by drawing on context information and taxonomy information. For example, it states "Typically, one label in a rendering may represent the taxonomy label for an element and another composite label may describe the context, unit and precision." It would be easier to assess if this kind of requirement was revisited with the experience we have gained since publication.
3.10 "... The content of descriptive headings MAY be based on the labels of elements, including abstract elements, in referenced taxonomies. ..." Not met. iXBRL does allow rendering data to include section headings but there is nothing in the specification to support lookup of taxonomy information like abstract element names to populate the heading. Software that does an iXBRL rendering could do such a lookup of course, but that is proprietary and not a part of the specification, as anticipated by this requirement.
3.11 "A standardised rendering method MUST enable the identification of important data which should be highlighted in a rendering. It MUST allow multiple levels of highlighting without imposing any limit on the number of available levels. It MUST allow any level of highlighting to be applied to any row, column or individual item of data in a standardised rendering of an instance, including descriptive headings. Examples of data which taxonomy authors or instance preparers may wish to highlight in different ways include totals and sub-totals, data with a particular context, such as a specific currency, audited and unaudited data, and different classes of information, such as domestic and foreign data. The standardised rendering method is only required to identify levels of highlighting and the data to which each level applies. It is NOT required to determine the specific means of highlighting or of distinguishing between different levels of emphasis. This is a presentational issue and is application specific. (Possible means of highlighting which may be adopted by applications include varying size and types of font and underlining, bold, line spaces and colour.)." Not met in that iXBRL does enable any kind of formatting to be applied to fact values. However, it does not allow users to capture the ordering of emphasis that the requirement indicates is the essence of what should be captured. In otherwords, iXBRL does what the requirement states is not necessary and does not do what the requirement states is necessary.
3.12 "Footnotes": Met.
3.13 "Unbroken data": Only met because the requirement implies that renderings other than HTML are expected (otherwise there would be no concern about being able to control page flow etc) but iXBRL eliminates those issues by only allowing HTML renderings.
3.14 "Paper and screen" Met.
3.15 "Embedding of data in text" Not met: This is an explicit statement of something that is not required and is explicitly indicated as a feature to leave up to applications but that is a feature of iXBRL. This kind of misalignment fuels my concern about the iXBRL spec and should be addressed by reviewing the requirements - perhaps just deleting this one.
3.16 "A standardised rendering method is NOT required to support the application of particular formatting such as font, bold, underlining, spacing or colour to any text or numbers, including monetary values. This is part of presentation which is out-of-scope and the province of specialised rendering applications. (Such applications may be expected to handle a variety of international writing systems, number representation systems, character sets, conventions and other presentational features.)" Not met: This is a clear limitation on what is expected and having a design like iXBRL that delivers so well on what is not required but that delivers in such a limited way on what is required should be a concern.
3.17 "A standardised rendering method MUST be able to reflect all relevant information in the DTS of an instance. The method MUST NOT be limited to using information in a base taxonomy: it MUST be able to handle any type of extension while meeting the other requirements set out in this document." Not met: This implies that the rendering metadata should be able to contain connections to all kinds of DTS information. iXBRL makes such connections application specific.
3.18. "A standardised rendering method MUST enable taxonomy authors or instance preparers to define alternative renderings for an instance, including alternative data groupings, ordering, and labelling. It MUST support practical means for users to select between the alternatives provided. For example, users may wish to arrange data in different sections and under differing headings depending on the prospective audience. A preparer may want to apply one layout to a report generated from an instance for senior management and a different layout for sales management. Clearly, this could be achieved by manipulating the output of a standardised rendering method in a suitable reporting tool, but this may involve significant effort, and it will typically be much more efficient to generate the different structures at source." Not met. The one instance can only be inlined with iXBRL in a single rendering.
3.19 "A standardised rendering method MUST be “format neutral” in that it MUST NOT assume or force the use of a particular solution or file format for the final rendering of instance documents. Similarly, it MUST NOT prevent the use of common file formats. Preparers and consumers may wish to generate reports from instances in a variety of formats, including HTML, XLS and PDF." Not met. iXBRL enforces HTML.
3.20 "A standardised rendering method MUST enable rendering metadata to be created easily and efficiently by taxonomy authors and instance preparers. ... A simple example is that a standardised rendering method MUST enable different values representing an item in a tuple to be handled in a consistent way, not forcing an instance creator into a series of repetitive actions to apply the same rendering definition to each value. " Not met. taxonomy authors cannot create rendering metadata using iXBRL. Moreover, in the simple example, there is nothing in the iXBRL specification that would lead to the kind of labour saving described. Such connections between rendering and tuple structures or repeated contexts etc all remain application specific.
4.1 "The rendering solution MUST enable an instance preparer to include formatted content from an external file other than the instance and its DTS. This would allow externally sourced content to be mixed with instance-based data in a standardised rendering." Rejected by VWG on the following grounds: "This was rejected as out-of-scope of a standardised XBRL rendering method, which is intended only to cover the rendering of data in a single instance and its DTS. Mixing of XBRL-based and other data raises a range of definitional and technical issues. It would undermine the ability to provide assurance on XBRL instances using standard renderings, since such renderings could contain external data not based on the instance. Such data might conflict with the content of the instance, as well as changing over time. The creation of composite documents containing XBRL and other data is the province of specialist applications, which may used a standardised XBRL rendering method as an input." XBRL violates this rejected requirement in spirit by including HTML markup information that is in addition to the instance and the supporting DTS. In my view it runs into the the definitional and technical issues that were anticipated by the VWG when the requirement was rejected.
Further comments by Peter Calvert on this feedback
I do not agree with Geoff’s assessment on requirements.
The fact that Inline XBRL goes beyond the stated requirements is hardly a problem – nor does it imply that the additional features which it provides do not matter. Rather, at the time the requirements were written, these presentational features were considered too difficult for an XBRL rendering mechanism – so we left them for specialist rendering applications to solve. The fact that iXBRL supports these features AND meets the original requirements is a huge plus for iXBRL.
I am not going to go through each requirement individually because that will just lead to repeated disagreement on each point. The underlying problem is that we are getting into semantic wrangling and the imputing of particular meaning to the requirements.
For example, consider requirements 3.7 (grouping and ordering) and 3.8 (tables). Inline XBRL DOES meet those requirements. The creator of an iXBRL document CAN order data into rows, define these in terms of any element, context, etc and create sub-sections. The creator can also determine their order (the meta-data for this is effectively within the XHTML document).
Similarly, consider requirements 3.9 on labels and labelling. All these are met. The creator of an iXBRL document CAN select labels from a referenced taxonomy. What is stopping them? The requirements do not say that a functional mechanism has to exist to place the labels automatically into a rendering. Equally, I cannot understand how iXBRL fails to meet requirement 3.11 on highlighting of important data. The creator of an iXBRL document can obviously highlight whatever they want in any way they think appropriate.
And so forth… similar comments could be made on all the other requirements, apart from those which explicitly refer to taxonomy metadata and 3.19 on file formats, which it has been acknowledged that iXBRL does not attempt to cover.
An underlying point is that the mechanism for achieving these requirements, iXBRL, is, as Geoff correctly points out, not the technical approach which was at the back of our minds when the requirements were written. Fine. But that does not mean the requirements are not met. They are – just not in the way Geoff perhaps expected. (Geoff’s comment about “underlying expectation” of the requirements and similar points rather emphasise that we are getting into expectations and interpretation, rather than what the requirements actually say.)
This debate over the meeting of requirements has reached a point where it does not seem very helpful. It has not clarified, for me at least, Geoff’s specific objections to the iXBRL spec. I think we should more usefully concentrate on the specific points raised on the iXBRL spec itself. We may have to agree to disagree on the requirements.
1a. Completeness of the use cases
Before CR release, I would like to see the use case documentation extended to reflect the feedback at:
http://wiki.xbrl.org/wiki/Feedback_on_inline_XBRL_use_cases
2. Limitation to embedding in HTML
The abstract states that "Inline XBRL is a standard for embedding XBRL fragments into an HTML document". In discussion of the use cases motivating the specification with the author of those use cases, it was evident that limitation of inline XBRL to embedding in HTML rather than any XML was significant. The WG should clarify the use cases and requirements to better motivate this limitation or the limitation should be eliminated. At the very least, the technical rationale for the limitation, if there is any, should be included in an overview document that accompanies any future publication of the specification.
Comments from Philip Allen
The genesis of Inline XBRL was the need to be able to display documents using commonly-available and easily implementable technology - in other words, HTML. In writing the spec., however, we recognised that conceptually Inline XBRL could apply to many other XML standards. The issue, though, was that there were no currently-credible use cases for any host format other than HTML; so we reluctantly put the wider case to one side and concentrated on HTML.
It should be very clear that the actual specification has been written, as far as possible, to be largely independent of the host format. Should the need for other host formats emerge, I would expect it would be possible to abstract the present specification from its reliance on HTML and recast it independent of the host format. But at this stage such an approach would unnecessarily complicate our task and make it rather more difficult to understand the specification.
Geoff Shuetrim:
- I think that the inference from commonly available and easily implementable to HTML is too great but that is just a personal opinion. SVG is a perfectly relevant alternative that is similarly easily implementable and is increasingly commonly available. The idea that financial reports have no role for graphics seems to be fundamentally incorrect.
- AFAIK to widen the specification's applicability, we could simply change the limitation that markup cannot be in the HTML header to be more broadly stated in terms of the outcome that we are trying to achieve by imposing that specific constraint. Some more information on what exactly the constraint is trying to achieve would really help me to ascertain the nature of the change that is required.
- Regarding simplicity of the specification, I think that the spec would actually be simpler if this limitation to HTML was eliminated. What kinds of complexities are you concerned about introducing?
3. Suspect implied DTS definition
5.1.1 states: The ix:footnoteLink element MUST adhere to the validation rules for extended links described in Section 3.5.3 "Extended links" in the [XBRL 2.1] specification, where the discoverable taxonomy set is taken to be the current Inline XBRL Document.
I do not see how an inline XBRL document can BE a DTS. It can imply one or more DTS's but it is not one itself.
Response from Walter Hamscher
Apparently this was meant to indicate the DTS rooted at the Target instance, since a DTS can't be rooted at an Inline XBRL Document. So, actually enforcing this validation would contravene 3.3 that reads "It should never be necessary for a processor to access the DTS of the Target Document when carrying out the transformation. Whether it does so will depend upon the design of the processor." So, here are two options:
1. Strike 5.1.1 as unnecessary; 3.2 says the output has to be XBRL-valid, therefore in conjunction with 3.3., validating after the transformation is already implied.
2. Copy from Section 3.5.3 "Extended links" in the XBRL 2.1 specification just those syntax constraints that can be validated without accessing the full DTS (e.g. XML Schema content model of footnoteLink and its children), and make 5.1.1 deal only with those.
Geoff Shuetrim: That fix will be fine I think.
Comment from Philip Allen
I have removed 5.1.1. All the s.3.5.3 requirements are covered in the Schema and therefore do not need to be enumerated in this Specification.
4. Naming and definition of concept-footnote relationships
The specification refers to but does not define concept-footnote relationships. They should be defined somewhere. Also, relationships in footnote links are generally from facts to footnotes rather than from concepts to footnotes. The naming choice for the relationships should reflect this.
Response from Walter Hamscher
Yes; concept-footnote is wrong, it should be fact-footnote. But definining that as the XLink relationships is sufficient. Further limitations, e.g. to the existing fact-footnote arcrole would probably have to change later.
Response from Philip Allen
Fixed in specification.
5. Hidden footnote resources.
Relationships from facts to hidden footnote resources seem to require an arc in the ix:footnoteLink element. If this understanding is correct, we should be careful not to contravene the following requirements for usage of the arcrole value defined in the XBRL 2.1 spec:
4.11.1.3.1 xlink:arcrole attributes on footnoteArc elements The value of the xlink:arcrole attribute MUST be a URI that indicates the meaning of the arc.
One standard arc role value has been defined for arc role values on footnoteArc elements. Its value is:
http://www.xbrl.org/2003/arcrole/fact-footnote
This arc role value is for use on a footnoteArc from item or tuple locators to footnote resources and it indicates that the footnote conveys human-readable information about the fact or facts.
Importantly, note that this constraint on the sources and targets of such arcs makes no mention of the nature of the containing extended link element.
Response from Walter Hamscher
I don't see how we can contravene these requirements, since these constraints aren't anything that a validator can detect? Perhaps you mean that there's only one arcrole defined in the 2.1 specification, but that's why there's a <ix:references> element so that other arcroles could appear.
Geoff Shuetrim: I may be reading the spec incorrectly but the constraint does seem to be possible to detect. My assumptions are:
- The relationship is expressed by a link:footnoteArc element
- The arc expressing the relationship has the standard arcrole value (hopefully this is where I err in my reading of the spec)
- The arc connects a fact with a hidden external resource such as a footnote expressed in an alternative language.
Together those are possible to detect and are a violation of the 2.1 spec. I think it would need to be fixed by having a new arcrole value that is then translated to the standard arcrole value when producing the XBRL instance.
Comment from Philip Allen
As I understand you (and it's quite possible that I have it wrong), you are saying that we are misusing the standard arcrole because this isn't a fact-footnote relationship, it's a fact-hidden footnote relationship? I don't think the 2.1 Spec constraints hold good here - we haven't incorporated them into the iXBRL spec. All we care about is that when we follow the Mapping Rules we end up with something that *does* follow the 2.1 Spec.
Comment from Geoff Shuetrim
You are right that the container for the arc is different in the iXBRL specification. I am not sure I buy that that difference is sufficient to allow you to use the arcrole in ways prohibited by the XBRL 2.1 spec when the XBRL 2.1 spec defines the arc and arcrole without limiting that definition to arcs within footnote links within XBRL instances. If it were me I would just use a different arcrole or highlight in the iXBRL spec that this is not a fact-footnote arc as described in the XBRL 2.1 spec despite using the same namespace and local name etc.
6. Treatment of external definitions
Terms like s-equal, that are defined in other specifications should use a hyperlink to the section of those other specifications where the terms are defined.
Response from Walter Hamscher
There are over 950 such occurrences. The style used in this spec was to use (say) xbrli:context Element instead of (say) simply "context" and a hyperlink. If it's important, okay, but is the effort necessary?
Response from Philip Allen
s-equal and other terms have now all been referenced to their canonical source in the "conventions" section. When referring to them under the conventions section I think it is probably more appropriate to provide document-level and not paragraph-level links.
Geoff Shuetrim: The technology is there to link to the paragraph level and that is the approach used in the formula specs but if the XSB is OK with document level references, the extra work for readers is OK by me.
7. ix Denominator and numerator sign attributes
Geoff Shuetrim: This is a pure editing error by myself in the original email. I had trouble coming to terms with the interpretation of the attribute but it worked out OK in the end. I am OK with this feature of the syntax remaining unchanged.
Response from Walter Hamscher
The text here doesn't match the heading, but, I assume what you're pointing out is that the ix:sign attribute on the ix:fraction element isn't mentioned in 6.2.3's mapping rules. I would only be guessing at the intent of requiring ix:sign, if present, to be "-". My inclination would be to get rid of the ix:sign attribute on ix:fraction and of course leave it on the numerator and denominator, but Philip should comment.
8. How does iXBRL handle mapping of non-XBRL defined attributes onto the fraction items in target instances?
Given that such attributes are permitted, it seems unreasonable to limit iXBRL to only being usable for that subset of XBRL instances that do not have such attributes. In general, we should be careful with mapping rules to avoid being closed when the XBRL 2.1 spec is open. Similar concerns relate to other mapping rules from iXBRL to facts in target XBRL instance documents.
Response from Walter Hamscher
Is this comment fraction-specific? The -ixmod declarations of XBRL content models have <anyAttribute namespace="##other" processContents="lax" /> on the fact attribute group. But the numerator and denominator elements don't have the fact attribute group. So I think maybe the comment is really about the XBRL specification's own closed declarations of numerator and denominator?
But if this is not a fraction-specific comment, is it more generally a comment that there is no way to "pass through" non-XBRL attributes from ix: elements into xbrl facts? Although that seems easy to add to transformation rules, I suspect it would hair up the modular HTML definitions and I'm not seeing the value add for the most likely use cases.
Geoff Shuetrim: The comment is not fraction specific. I am OK with leaving the feature out but if we do so then we should add a note in the introduction indicating that not all XBRL instances will be possible to embed in iXBRL and then we should provide examples of the kinds of limitations that exist.
Comment from Philip Allen
I agree. Documentation is the least-worst option.
9. Section 7.1.1 The ix:header element MUST NOT be a child of the head element.
What is the "head" element? We should be explicit in the spec about what elements without namespace prefixes or with names that are not QNames actually are.
Generally, the treatmet of the ix:header seems to be where the spec meets with HTML. I think that small changes to this part would enable support of embedding XBRL into a broad range of XML structures.
Response from Walter Hamscher
Minor edit made. It is may be true that generalization here would be possible, but a sensible process for generalizing beyond HTML would be to document the requirements of such an approach first.
Response from Philip Allen
Fixed in specification.
10. The specification still fails to support connection of context information to information rendered in the browser.
This needs to be overcome if the specification is to have my support. The arbitrary distinction made between the importance of connections between fact values and rendered information and fact aspects and rendered information is not at all well supported by any use cases that have been put forward to motivate the specification.
Entity identifiers, units, periods etc are all important when assessing the match between the facts in the XBRL instances and the rendered information. Not being able to capture this connection is, to my mind, a major shortcoming.
Response from Walter Hamscher
Perhaps a shortcoming, but also requiring a major rework. DecisionSoft's prototypes from around October 2007 took an approach I rather liked which was to dispense with the context elements in the source document and pack all of the entity, segment and period values into attributes of (what would now be) the ix: elements; the problem of course was the open ended syntax of contexts, not to mention the bloat and redundancy in the source file that would cause (even though the extraction processor could collapse equivalent contexts). Perhaps a middle way would be to provide new ix: elements (not necessarily inside ix:hidden) that would define aspects, give them id's to be referenced from ix: elements. In any event this is hardly a show stopper, is it? Those additional elements for defining aspects could be added to the ix: namespace in a subsequent edition.
Geoff Shuetrim: I agree that this involves a significant rework and that is why I keep banging so retentive about getting the requirements and use cases straight. I personally think that the design on the table is holding us back from having an effective means of addressing this issue. I think that the suggested solution of defining new elements in an ix namespace in a new spec would be challenging given the open ended nature of typed dimensions. My view is that an alternative design, not mixing the rendering information and the data, would provide a better foundation for addressing this shortcoming.
Response from Philip Allen
We felt at the outset that the display of context information in an HTML document was of a fundamentally different order to the display of fact information. Context information is information about the facts; not a fact itself. The alternative approach, of treating each displayed item of context information as having value in the Target Document, introduces a series of further issues - for instance: links to reflect the multiple re-use of context information; transformations between displayed and Target values; and a requirement to test that all displayed context information is the same. The latter is a particularly thorny problem, because it is not at all the case that a given financial report will display a given piece of context information in the same way in all circumstances. This leads us ineluctably to the conclusion that it is up to the author of the iXBRL document whether or not context information is tagged or not. This is objectionable because it becomes far more difficult to assure that what you see is what ends up in the Target Document. Taken together, there is a very strong case for ignoring context information, in favour of simplicity, ease of use, and assurance of the finished document. It is this route that we have taken.
Geoff Shuetrim: The distinction in importance between the fact value and the context value is arbitrary and misleading. Having a identity relationship between rendered and reported fact values means nothing from an assurance or data integrity perspective if you have no accompanying assurance that the context for the reported fact is also driving the rendering of the contextual information for the fact in the rendered document. Regarding the further issues that you raise, I will try to address them individually.
- You rightly note that there is a one to many relationship between contexts and facts - causing any solution to involve linking. I think that should be used as an insight in designing the spec. It should be noted that this issue (one to many relationship) already exists for us in relation to renderings that require the same fact value to be rendered twice in the one rendered document. If we develop a solution that handles contexts, we will also be able to resolve that problem.
- You indicate that there is a requirement to test that all displayed context information is the same. I am not sure I really understand this issue. Would it be possible for you to outline the kind of tests that you have in mind? When I think about this, I have some tabular structure in mind with a series of aspects (including the concept itself) driving the rows and columns of the presentation. In looking at such a table, I want to know: are the values in the table cells the values being reported (already partially covered by the current spec); are the values being shown in the right cells (not handled); and are the rows and columns being labelled correctly (not handled)? A linking solution seems to be the right way to give me that knowledge.
- You indicate that a given financial report will display a given piece of context information in different ways. Perhaps I am missing the point but could this not be handled with the same solution as is being applied to address transformations from rendered fact values to XBRL valid fact values?
11. Sections 9.1 and 10.1
"It is common to include formatting in displayed numbers, such as group separators, which are not valid in the Inline XBRL Document. Inline XBRL uses Transformation Rules to transform such items into values which will be acceptable in the Target Document."
"Certain XBRL items, such as those of type xbrli:booleanItemType, xbrli:dateTimeItemType and xbrli:timeItemType (amongst others) have content constraints which may not be met when displayed in the Inline XBRL Document. Inline XBRL uses Transformation Rule to transform such items into values which will be acceptable in the Target Document."
The formats are potentially invalid in the extracted XBRL document, rather than being invalid in the inline XBRL document. I think the wording needs to reflect this.
Response from Walter Hamscher
Good catch. How's this:
"It is common to include formatting in displayed numbers, such as group separators, which would not be valid in the Target Document. Inline XBRL uses Transformation Rules to transform such items into values that will be valid in the Target Document."
"Certain XBRL items, such as those of type xbrli:booleanItemType, xbrli:dateTimeItemType and xbrli:timeItemType (amongst others) have content constraints that may not be met when displayed in the Inline XBRL Document. Inline XBRL uses Transformation Rules to transform the items as displayed into values that will be valid in the Target Document."
Geoff Shuetrim: That looks perfect.
Comment from Philip Allen
Fixed in specification.
12. Sign, scaling and formatting transformations but no rounding rules?
The specification allow for explicit handling of mappings between the scaling and formatting of rendered fact values and XBRL fact values. However, it does not explicitly handle rounding/truncation rules. That seems to be a significant shortcoming of the existing specification.
Response from Walter Hamscher
That seems backwards but let me play this out. Rounding/truncations are operations that take you from a number to a different number that is less precise. So you are thinking here of a use case in which you've got a displayed number that is more precise than the XBRL value you want to extract... so you want to throw away digits during extraction? And the problem is that just specifying decimals and precision attributes on ix:nonFraction doesn't give you that flexibility? Or am I reading to much into this and all you mean is that you want the specification's (non-normative) transformation rules to be more explicit as to what they do with the digits in their inputs? I suppose there is something in all this relating to the acceptance radius.
Geoff Shuetrim: I have been thinking about the potential to want high precision in the actual XBRL instance and low precision in the presentation. For instance, the actual amount to be specified in the instance is 123456789 with a precision of zero decimal places. If the value is scaled to be rendered in millions you want the instance to display 123 as the rendered value, not 123.456789. The question is, how do you recover the 456789 part of the number when then going from the rendering of the instance to the instance that you want to provide? (At the moment, I do not think this needs to be tied back to the acceptance radius.) That seems more thorny and more common than the case where you want to throw data away when going from the rendering to the instance.
Comment from Philip Allen
I agree that this is difficult. The only solution is to include the more detailed figure (the .457689 or the 123.457689) in another, non-displayed location. I.E., in ix:hidden or in an attribute value. The latter falls clearly foul of the "what I see is what I get" concept which underpins this spec. Putting it in ix:hidden means we get two values for the same item which have to be reconciled - and could amount to repeating the entire set of facts in ix:hidden. Ugh. With regret, I think it's easier to impose the restriction of "no un-rounding".
E-mail from Dave Raggett
I have looked through the Inline XBRL specification and have a number of comments that you could pass on to the working group.
My recommendation is that
1) Inline XBRL should be designed to allow for delivery as text/html, and as such, should avoid the use of XML namespaces. New elements should also be avoided as these aren't exposed to the web page DOM in a reliable cross browser way.
2) The proposed XHTML XBRL module could be retained for delivery as application/xhtml+xml, but it should be noted that this would have limited use with existing browsers due to lack of support on the most common browser Internet Explorer.
This recommendation would enable web pages that act as mashups, extracting the XBRL semantics from web pages and adding value in numerous ways.
Details follow below:
The objective is stated in the abstract as being:
"to provide documents which can be viewed in a browser while making use of XBRL tags which can be processed automatically by consuming applications."
Current browsers support text/html and have only limited support for application/xhtml+xml which is recommended for XHTML by:
http://www.w3.org/TR/xhtml-media-types/
In particular, the most commonly used browser, Internet Explorer (IE) doesn't support application/xhtml+xml, see e.g. Chris Wilson's blog:
http://blogs.msdn.com/ie/archive/2005/09/15/467901.aspx
Chris is the Platform Architect of the Internet Explorer Platform team at Microsoft, and co-chair of the W3C HTML5 working group.
As a result of the lack of support by IE, it is common practice to deliver XHTML documents as text/html, and for browsers to process these documents as if they are HTML.
Ian Hickson, the HTML5 specification editor, gives his views of the problems that arise in practice when XHTML is delivered as text/html:
http://hixie.ch/advocacy/xhtml
Ian notes that when delivering XHTML as text/html, people write their scripts and style sheets to match the familiar processing rules for HTML, e.g. case insensitivity, the use of document.write, no need to escape the content of script and style elements. If the same document is then served as application/xhtml+xml, it will fail to work as expected. My own experiments have shown that beyond these problems there are additional subtle differences in the scripting interfaces exposed by browsers for the two MIME types.
If we assume that content is delivered as text/html, what the pros and cons for using XML namespaces and additional elements that aren't part of HTML4?
Browsers are good at ignoring unknown tags and process the document essentially as if these tags weren't part of the input stream. Browsers differ in whether such tags appear in the DOM tree. That causes big problems for web-page mashups that want to scan the DOM tree for such markup.
XML namespaces aren't supported for documents delived as text/html, and although there are some limited work arounds, these involve tricky scripting hacks that are highly browser specific.
In IE, you have to define a namespace in order for new elements to be exposed in the DOM and stylable with CSS. However, IE doesn't support the DOM getElementsByTagNameNS() method, and you instead need to the regular getElementsByTagName method and look at the namespace value. IE also requires the namespace prefix on each such tag as it doesn't support inheritance of the default namespace.
Firefox exposes namespaced elements in the DOM as upper case regardless of their original casing. Opera Software state that they discontinued support for namespaces with Opera 9, see:
http://www.opera.com/docs/specs/
The DOM exposes the literal name of the tag including its prefix. In principle, you could use JavaScript to look for namespace definitions as part of a namespace aware library, but that would be quite hard to do in a way that works across browsers. As a result, I would advise against using non-html elements if you want to allow for web page scripts that process these elements for documents delivered as text/html.
Browsers are much better at handling unknown attributes on existing html elements. The namespace prefix is exposed as part of the attribute name, and web page scripts can be written to search for the namespace definition by scanning the element and its ancestors. However, the feeling in the HTML5 working group is to avoid the use of XML namespace prefixes for attributes and to instead use a string literal prefix for such attributes.
This issue has surfaced in the debate over how to annotate rich web applications with information that will allow browsers to support accessibility interfaces for assistive technology. For instance, WAI-ARIA proposes the following for text/html:
<span role="checkbox" aria-checked="mixed"
onkeydown="return checkBoxEvent(event);"
onclick="return checkBoxEvent(event);" >
A checkbox label
</span>
see http://www.w3.org/TR/wai-aria/#introstates
For XHTML WAI-ARIA proposes XML namespaces for ARIA specific attributes, and a QName for the role attribute value, e.g.
<span
class="checkbox"
id="chbox1"
role="ariarole:checkbox"
aria:checked="true"
tabindex="0"
onkeydown="return checkBoxEvent(event);"
onkeyup="return checkBoxEvent(event);" >
A checkbox label
</span>
See http://www.w3.org/TR/wai-aria/#implementation
WAI-ARIA acknowledges that text/html doesn't support XML namespaces and provides an alternative solution using the "aria-" prefix and calling upon the HTML5 working group to include this and the role attribute as part of the HTML5 specification.
I would strongly encourage XBRL International to consider doing something along the same lines as WAI-ARIA when it comes to delivering XBRL to web browsers. In particular, this would define new attributes for use on existing html elements with a unique prefix such as "xbrl-". The proposed XHTML XBRL module could be retained for delivery as application/xhtml+xml, but it should be noted that this would have limited use with existing browsers.
Comments on Dave Raggett's email by Walter Hamscher
I disagree with the conclusion. text/html seems to me the least of evils. Dave alludes to problems with using elements in IE in the section beginning "If we assume that content is delivered as text/html, " but it seems to me that rather than changing the specification we just take the part where Dave discusses those implications of delivery as text/html and write a separate note on (i) style guidance for authors and (ii) warnings for consuming applications regarding DOM incompatibilities.
Comments on Dave Raggett's email by Ian Stokes-Rees
I agree with Walter's position. iXBRL designed to be compatible with JavaScript and IE's HTML DOM processing should not be a priority. Having to accept case-insensitivity would be a particular nightmare for processing. Considerations of data quality preservation and processing should continue to take precedence here.
Comments on Dave Raggett's email by Philip Allen
I agree that we need to provide some documentation around these points. However, the main question here amounts to whether or not the syntax of Inline XBRL should be "element-centric" or "microformatty". This was discussed by the Working Group at length at the turn of the year, and it was decided at that time not to follow the microformatty approach. I see no reason to revisit that decision at this point.
E-mail from Holger Obst and response from Philip Allen
On Tuesday 20 May 2008 12:18:55 Holger Obst wrote:
>
> a short question as we run into an issue with inline XBRL, or at least
> I'm lost how inline XBRL is handling things like below:
>
> <span property="issue_date" content="2007-06-01">Jun. 2007</span>
>
> This is the structure I normally know from other microformats. For
> example a human will understand Jun 2007. But for XBRL you need the date
> as computer readable 2007-06-01. how to express this with inline XBRL?
>
> I would appreciate an answer and looking forward to here from you.
>
The iXBRL syntax could look like this:
<ix:nonNumeric ix:name="abc:conceptName" ix:format="datemonthfirst" contextRef="ABC">Jun. 2007</ix:nonNumeric>
The value of ix:format is a format code which must be listed in the forthcoming Transformation Rules registry. The transformation rules convert the text content of the ix:nonNumeric element into the value required for the XBRL instance document. See section 14 in the specification.
On Tuesday 20 May 2008 13:07:36 Holger Obst wrote:
>
> ok, I understand now. But this is a really complex way, isn't it? Is
> this transformation rule mechanism used in other xml standards? I mean
> how to handle this registry, this could be very complex and already
> restricting financial reporting. Is there a reason why not introducing
> an attribute to keep the XBRL content? What is the idea behind?
One of the fundamental principles of iXBRL is NOT to duplicate information. Thus, data MUST be entered as element content and not as attributes. The reason for this is the emphasis on assurance - the ability to determine that there is an appropriate relationship between what is displayed and what is in the XBRL instance document.
> Also who is handling the registry?
>
> "A normative list of additions to the list of Transformation Rules with
> normative rules for format conversions and sample transformation code
> will be maintained by XBRL International, Inc. at [location]."??
The current PWD of the specification reads:
"The normative list of Transformation Rules and associated transformation code will be accessible through a registry which will be maintained under the authority of XBRL International, Inc. The registry mechanism will operate in accordance with a forthcoming registry specification."
You will note that the registry will not necessarily be maintained BY the consortium. We want to allow subsidiarity; but also to put in place a mechanism to allow de-duplication of rules and a sensible naming convention for format codes.
I will be discussing this with the Rendering WG in forthcoming weeks. If you have any specific requests about how the registry should operate (your point about Arabic etc. is important here) then please let me know.
> And more important, is it also working with languages like Arabic,
> Chinese etc - this is very important for us! Could you please address my
> concern here in your discussion? I see disadvantages in this
> transformation registry approach as explained above. I would suggest a
> special attribute. If the attribute is available a processor should take
> the content of the attribute for fact content and ignoring the included
> textnode.