May 12, 2017
Below is a somewhat technical overview in response to the Inline XBRL SEC mandate proposal(File Number S7-03-17). I believe this is appropriate due to the scope of the proposal and to broadly address the many concerns expressed by the SEC staff.
Inline XBRL should be an easy decision, since having an HTML or ASCII page lacking any formal reference to the XBRL "instance" is seen as "not rational" ....and subject to quality issues caused by duplicate reporting inconsistencies. Now that XBRL Interactive data and XML instances are well-established, all publications mirrored by the XBRL should be cross-referenced. Even the "Interactive Data" automated from presentation linkbases is oddly published without these cross-references that are readily available during generation. Exports to Excel would benefit greatly with instance cross-references passed through. Common sense would dictate that all reporting fragments, if not full inline xbrl, always have, at least, an id cross-reference to the item's unique id as assigned in the related XBRL instance file. (The html class="" attribute might be a good candidate for this functionality.)
The acknowledged success of Inline XBRL internationally may not be representative for the SEC's Inline Mandate. What is always glossed over is the obvious contrast of simple Inline XBRL, instances without linkbases/taxonomies, versus the full-scale technical aspects of the existing SEC system. The world-wide inline projects are more a model for other SEC reporting needs possible with boiler-plate structures, those suitable to being limited to only instance and xml schema files.
Providing the Inline XBRL Viewer is a great step forward in leveraging the richness of XBRL taxonomies and definitely can promote understanding and appreciation for XBRL among readers. However, in regard to creating filings and accessing the actual inline documents, the viewer app is more of an impediment, since the document links will direct the browser to an application screen. This was a bad deployment decision in my opinion. Also, I believe that the SEC should standardize an official text-phrase in inline documents; so that IXBRL documents can be found in the "Full Text" search on the SEC website.
Inline XBRL documents are HTML and should not be published with <DOCUMENT> and other system control references before the root <html ... > tag. These would be better carried as xml comments or as processing instructions(i.e <?DOCUMENT?> for example).
Empty XML tags are not interpreted properly by browser engines, so the SEC should require elements like <ix:relationship ... /> to be written using a closing tag as <ix:relationship ... ></ix:relationship>. Otherwise the browser slows down since the DOM now contains a non-sensical nested structure as deep as the number of successive empty tags.
Inline XBRL as a standard is written in such a way that HTML/XHTML is not automatically assumed as the publishing medium. However, this perspective de-emphacizes the dynamic nature and advantages unique to HTML. Just as the SEC has a viewer that is scripted in-page, the conversion of numbers to the final XML equvalent can be performed and added as an attribute such as instancetxt="22500000". This attribute would be automated "live" and never pre-existing as a fixed field in the original html markup. Applications adding this scripted attribute will encourage extraction software development.
Software to edit Inline XBRL html can be based on the modern developer tools built into current web browsers. This is a visual environment that allows access to maintaining cursor positioning within the associated source-code pane ... so thet non-technical users are not tempted to wade through complete source files. My recomendation is that vendors exploit this technology by developing desktop tools built on the new ELectron platform. Also, document creators should not be constrained to the XHTML limitations, XBRL syntax/naming or filer manual restrictions when creating html documents: ...editing environments should use the full power of HTML5 and then convert to compliance only as a transformation final step.
My company has already developed many mini-tools that manipulate and expose the internal info of a browser-displayed Inline XBRL document. Also, we have created special mini-apps(live in the browser) that, for example, "post" visible lists of IXBRL attributes into placeholders within a plain HTML page avoiding edits to raw-source markup. I am convinced it will be easier to create new Inline XBRL editing tools, because of capabilities inherent in HTML and browser environments. Our projects/examples and further elaboration about these technical and other observations will be available on my blog at http://xbrlreview.blogspot.com/
Thank you for the opportunity to comment on your Inline XBRL proposals.
Bill Palmer
FOUNDER, R W Palmer Consulting
(May 12, 2017)