<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: XBRL Filings for the SEC: Not for the Faint of Heart (Part IV)</title>
	<atom:link href="http://hitachidatainteractive.com/2010/01/11/xbrl-filings-for-the-sec-not-for-the-faint-of-heart-part-iv/feed/" rel="self" type="application/rss+xml" />
	<link>http://hitachidatainteractive.com/2010/01/11/xbrl-filings-for-the-sec-not-for-the-faint-of-heart-part-iv/</link>
	<description>XBRL News and Commentary from the Hitachi XBRL Business Unit</description>
	<lastBuildDate>Wed, 11 Apr 2012 17:47:17 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.1.2</generator>
	<item>
		<title>By: SAX and Bugs and XBRooL &#171; Gobán Saor</title>
		<link>http://hitachidatainteractive.com/2010/01/11/xbrl-filings-for-the-sec-not-for-the-faint-of-heart-part-iv/comment-page-1/#comment-65853</link>
		<dc:creator>SAX and Bugs and XBRooL &#171; Gobán Saor</dc:creator>
		<pubDate>Thu, 06 May 2010 12:26:58 +0000</pubDate>
		<guid isPermaLink="false">http://hitachidatainteractive.com/?p=912#comment-65853</guid>
		<description>[...] XBRL has always been on the radar, and of late, the radar is showing incoming fire. First the SEC, and now the UK&#8217;s HMRC, are mandating it as a filing method. Whether this is a good thing or [...]</description>
		<content:encoded><![CDATA[<p>[...] XBRL has always been on the radar, and of late, the radar is showing incoming fire. First the SEC, and now the UK&#8217;s HMRC, are mandating it as a filing method. Whether this is a good thing or [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Raymond Lam</title>
		<link>http://hitachidatainteractive.com/2010/01/11/xbrl-filings-for-the-sec-not-for-the-faint-of-heart-part-iv/comment-page-1/#comment-50312</link>
		<dc:creator>Raymond Lam</dc:creator>
		<pubDate>Wed, 20 Jan 2010 13:38:09 +0000</pubDate>
		<guid isPermaLink="false">http://hitachidatainteractive.com/?p=912#comment-50312</guid>
		<description>Yes, truly not for the faint of heart. Detailed tagging is something that will certainly push the limits of XBRL - the specification and standard itself - as well as the software tools which will undoubtedly have to play a significant role in assisting users with their tagging needs.

There are indeed a number of HMI (human-machine-interface) issues which will need to be sorted out by industry in the months ahead in order for tools to make themselves genuinely useful, including: 
(1) the ability to tag at any arbitrary level of granularity in a source document, from section (aka block) to paragraphs to sentences and possibly right down to a specific run of characters and digits 
(2) the ability to handle the nesting of such tagging (for instance, if a number is tagged and it occurs in a tagged paragraph, what types of linkages will be required to show that such dependencies exist)
(3) the gap between what the user visually tags vs. what gets captured as XBRL metadata (for example, the tagging of a particular sentence or word may need to produce a boolean fact value instead of a string value)
(4) the ability of software to draw from history in order to assist users in subsequent filings

The task is daunting. Compare the text/prose content in any 10Q/K document against the face financials, and there is often an order of magnitude difference in terms of the volume of content which will need to be tagged.

This is a very interesting space at this point in the evolution and adoption of XBRL, and is one that bears a lot of attention.</description>
		<content:encoded><![CDATA[<p>Yes, truly not for the faint of heart. Detailed tagging is something that will certainly push the limits of XBRL - the specification and standard itself - as well as the software tools which will undoubtedly have to play a significant role in assisting users with their tagging needs.</p>
<p>There are indeed a number of HMI (human-machine-interface) issues which will need to be sorted out by industry in the months ahead in order for tools to make themselves genuinely useful, including:<br />
(1) the ability to tag at any arbitrary level of granularity in a source document, from section (aka block) to paragraphs to sentences and possibly right down to a specific run of characters and digits<br />
(2) the ability to handle the nesting of such tagging (for instance, if a number is tagged and it occurs in a tagged paragraph, what types of linkages will be required to show that such dependencies exist)<br />
(3) the gap between what the user visually tags vs. what gets captured as XBRL metadata (for example, the tagging of a particular sentence or word may need to produce a boolean fact value instead of a string value)<br />
(4) the ability of software to draw from history in order to assist users in subsequent filings</p>
<p>The task is daunting. Compare the text/prose content in any 10Q/K document against the face financials, and there is often an order of magnitude difference in terms of the volume of content which will need to be tagged.</p>
<p>This is a very interesting space at this point in the evolution and adoption of XBRL, and is one that bears a lot of attention.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

