Le Tue, Jan 15, 2008 at 02:28:24PM +0100, Daniel Leidert a écrit : > Am Dienstag, den 15.01.2008, 20:33 +0900 schrieb Charles Plessy: > > Le Tue, Jan 15, 2008 at 12:08:35PM +0100, Daniel Leidert a écrit : > > Well, I personally think, that we should *not* try to detect all broken > formats, because companies/authors should better fix their software. So > I try to make a compromise between the detection of a file with a broken > format and broken files that are "broken too much".
OK, then lines such as the following could be removed: <match type="string" value="COMPND " offset="0"/> <match type="string" value="CRYST1 " offset="0"/> <match type="string" value="DBREF " offset="0"/> except for: <match type="string" value="HEADER " offset="0"/> > I think the impact of renaming well established MIME > type names without a wide consensus (much wider than just between Debian > package maintainers) creates a bigger problem than using the unofficial > primary type "chemical". I know, the situation is not the best atm. > That's why I start discussions about it from tiem to time. You can find > the latest at: > http://www.nabble.com/Re:-SMILES-mime-types-p14229988.html. Good to know that 10 years after, people still care ! > > Maybe a solution would be to patch update-mime-database to make it > > accept chemical as a legitimate type: > > Or just output a warning once or do not output warnings for "x-" > prefixed primary types (which would allow us to use x-chemical and add > aliases to chemical/). Sure. Not being a C programmer, I can not propose a patch for this. > Creating a new RfC also means to define chemical/* types like text/plain > or application/octet-stream were defined in the MIME RfCs. So there are > currently a lot of chemical MIME types ... to be honest: much more than > during the original RfC in 1994/5. But we should try to avoid to use > chemical/* for every new chemistry related file format. We should be > careful and use appropriate existing primary types if possible. For > example: It doesn't make sense to name the gchempaint or gcrystal > formats chemical/*, because they are application specific and therefor > fit the application/ type much better. However, chemical/ was created, > because exchangeable chemical file formats do not fit into the existing > primary types. OK, to summarise: - If a chemical/* media type already exists, we will use it. - We will not create new chemical/* media types. - We will not migrate some types from chemical/* to text/*. - If somebody can propose a patch that reduces the size of the warning for using the chemical/* types, we will make our packages recommend chemical-mime-data, and file wishlist bugs wherever appropriate. Can you suggest an appropriate place where we can discuss about creating a media type for Clustal W alignments and trees ? Have a nice day, -- Charles Plessy http://charles.plessy.org Wakō, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
