[
Lists Home |
Date Index |
Thread Index
]
>>
Yes, the problem is the fidelity. There is a spectrum of content and the way
people approach content, from the extremely visual, through to the highly
structured (and possibly abstract). People who approach documents visually,
will have a very hard time authoring using styles... they'll want to fiddle
with fonts instead (how many documents have you seen where every style was
Normal?). In those cases, the original document, while it *should* be the
data source, most likely cannot be in any productive sense.
I once dealt with a bank that produced a book of credit reports (a *huge*
book). There were all kinds of uses the data could be put to, from setting
interest rates, approving loans, etc. onward *if* the data could be reused.
The problem was that in some cases, the credit reports were GIF images, in
other cases, Excel spreadsheets, and the rest were in everything between
them. The obvious solution was to standardize the data entry side so that
data could be accurately captured in XML, or somesuch, but that was
precisely
the thing that could *not* be done. Prototypes based around forms, word etc.
all failed, because the people entering data were underpaid and
undermotivated to enter data appropriately. This is an extreme case, but I
think there are many situations where siilar problems will raise their head.
While I applaud XML on the desktop, I'm not seeing a silver bullet...
<<
That's what XBRL is all about [1]. As an example various banks are providing
discounts to loan applicants who submit their applications tagged in XBRL.
This provides an incentive to the data provider to use this format. Software
is being created to facilitate that so the underpaid data entry clerk never
needs to see a pointy bracket. Various existing accounting software is
implementing 'export to XBRL' type features to relieve the burden.
Cheers
Hugh Wallis
[1] http://www.xbrl.org
|
