Metadata that is separate from the data has a way of being disassociated
from it. Annoying, but a fact of life. This can be as simple as file
creation dates not being preserved on copy.
Metadata that is contained in the same file as the data, has a way of
being incorrect. Look no further than HTML language tags or charset
declarations.
Then there is metadata that can be easily reconstituted from the data,
like file sizes, hash signatures or preview images (in many cases). They
are "meta" data only as a mater of convenience, since they don't add
information.
Unless there's a way to rebuild the metadata unambiguously or to enforce
that it is complete and correct, it's very hard to rely on it for any
particular purpose.
That issue isn't limited to a any particular vendor (whether major or
not), it's really in the nature of the beast.
A./
On 10/20/2012 2:39 PM, Doug Ewell wrote:
When a Major Software Company, which sells the Well-Known Operating
System that I and a few other people use and develop for, decides to
add character-encoding metadata to the file system of that OS, and
when versions of that file system that support encoding metadata are
widespread enough that I no longer need to target my apps to previous
versions, then I too will consider encoding detection to be a thing of
the past.
--
Doug Ewell | Thornton, Colorado, USA
http://www.ewellic.org | @DougEwell
-----Original Message----- From: Philippe Verdy
Sent: Friday, October 19, 2012 16:45
To: Doug Ewell
Cc: Stephan Stiller ; [email protected]
Subject: Re: texteditors that can process and save in different encodings
. I'm a strong supporter of
separately stored metadata. It is always possible in all filesystems,
even if this requires a convention for organizing the content of that
filesystem.
