Home → Problems (v2) →

Non-standard UTI for OPML files screws up system and compatibility

• Edit

deanishe

17 Aug, 2015 06:45 PM

MultiMarkdown Composer declares its own UTI for OPML files instead of using the de facto standard org.opml.opml.

As a result, after installing MMC, the Open With… menu, Smart Folders and other software that relies on UTIs (such as Alfred) no longer work properly.

The metadata subsystem becomes a mess, with some OPML files having the correct org.opml.opml UTI cached for them, and some files having the non-standard net.multimarkdown.opml UTI. As a result, Smart Folders or Alfred File Filters configured with org.opml.opml don't find files with the duff UTI. Similarly, apps that can open OPML files, like OmniOutliner, Tree etc., no longer show up in the Open With… menu for those newer files with the bad UTI.

I use OPML a lot, I use outliners a lot, and I use Alfred and Smart Folders a lot. Applications that define rogue OPML UTIs (like MMC, CloudOutliner, Downcast) cause me a lot of problems as a result. Seeing as MMC is just one of many (Multi)Markdown editors, it has to go in the trash and I have to rebuild my Spotlight index. It's not worth the hassle its rogue UTI causes me :(

In my opinion, this problem is caused by MMC misbehaving. Unlink MultiMarkdown (and the .mmd extension), OPML is not a format defined by MMC (or more exactly its developer), and as a result it's not MMC's place to create its own UTI for it when a standard one already exists.

It would be somewhat mitigated if MMC at least defined net.multimarkdown.opml as conforming to org.opml.opml, but I believe the best solution is to for applications not to define their own UTIs for common file formats for which standard (de facto or "de jure") UTIs already exist.

1. Support Staff 1 Posted by Fletcher on 18 Aug, 2015 02:39 PM

   

   Thanks for writing in with your comments.

   MultiMarkkdown itself (and MMD Composer) aren't compatible with just
   *any* OPML file -- it applies specific expectations to the format, just
   like MMD expects certain things from text files (and uses the
   `net.multimarkdown.text` UTI for text files.

   For this, and other, reasons, I don't believe that `public.plain-text`
   or `org.opml.opml` are the best UTIs for MMDC.

   Apple's UTI system is one of the most broken things (in my opinion) I
   have seen from Apple, and am surprised it has not been fixed. To me, it
   seems that it works in the exact opposite way that it should in many
   aspects.

   To my knowledge, OS X does not allow users to assign specific UTIs to a
   document, and instead relies on an opaque algorithm to choose a UTI for
   you, based on installed applications, filename extensions, etc. There
   seems to be no way for a user to assign precedence to specific
   applications (e.g. OmniOutliner should be higher priority than Composer
   when looking at `.opml` files)

   For the same reasons, an application is not able to rely on a specific
   UTI being used for a specific document type -- early versions of
   Composer used the UTI to determine what to do with a file, but I quickly
   learned this was unreliable and had to look specifically at the file
   content instead.

   The one saving grace (sort of) is that the Finder allows you to set a
   default application for specific documents, and for all documents of a
   specific type. For example, I use OmniOutliner Professional as my
   default application for OPML files, which means I use that application
   whenever I double click. If I want to open an OPML file with Composer,
   I drag to the app, or use the "Open with" contextual menu. I haven't
   had any problems with this approach.

   As for your issues with Alfred, you would probably be better off with a
   boolean OR of `org.opml.opml` UTI and `.opml` file extension. Because
   of Apple's UTI implementation decisions, neither by itself is fully
   reliable, depending on which apps you install (as you have discovered).

   I'll look back into having the opml type conform to `org.opml.opml` --
   I remember there being a reason why that was not a good idea, but that
   was several years ago and I don't remember what that reason was at the
   moment.

   Again -- thanks for writing in, and I share your frustrations with
   Apple's UTI system. And trust me, it's even more frustrating in my role
   as a developer than as a user....

   Fletcher

   • Edit

2. 2 Posted by deanishe on 19 Aug, 2015 09:37 PM

   

   Thanks for the fast and detailed reply.

   MultiMarkkdown itself (and MMD Composer) aren't compatible with just any OPML file -- it applies specific expectations to the format […] and uses the net.multimarkdown.text UTI for text files.

   For this, and other, reasons, I don't believe that public.plain-text or org.opml.opml are the best UTIs for MMDC.

   As you note, the whole UTI system is a great big mess. There's no way for MMDC to ensure the files it creates have its UTI. Consequently, there is no way for MMDC to know whether the files it opens are of the right format without looking at the content. The only way to do that is to give them a different extension.

   That is to say, I see this rather as a reason not to use custom UTIs unless you also use custom file extensions (like .mmd for Multimarkdown, instead of .md). Isn't that the whole point of having extensions like .md, .xml, .html or .csv instead of just using .txt for everything?

   As you say, there's no way of ensuring that Markdown or OPML files will have the UTIs that MMDC defines, especially as so many apps define their own, non-standard UTIs for these filetypes. If you can't rely on MMDC-compatible files having the net.multimarkdown.opml/text UTI, what's the benefit of it?

   I dare say there might be some reasons for developers, but it just makes life difficult for users, who end up with their files of the same type (and extension) having different UTIs because they installed/uninstalled some software. And again, as you note, there is no actual correspondence between which UTI is assigned and which app actually wrote the file (i.e. they can't be used to determine compatibility).

   I use OmniOutliner Professional as my default application for OPML files, which means I use that application
   whenever I double click.

   To be clear, opening files is a trivial issue (but please see the end of my comment), it's the messing up of file metadata that's the problem, whereby files of the same type have different UTIs.

   I'm not sure that the benefits of MMDC having its own custom UTI outweigh the potential to break a user's Smart Folders, Alfred File Filters and anything else that uses UTIs.

   As for your issues with Alfred, you would probably be better off with a boolean OR of org.opml.opml UTI and .opml file extension.

   This doesn't work. Alfred's File Filters are UTI-based only. Currently, you have to drop files on the file list to add their UTI to the search, which means hunting down a bunch of files of the same type, but differing UTIs to drop on it.

   This problem is enormously confusing for your average user who has no idea what a UTI even is.

   The latest beta of Alfred now allows you to add UTIs manually, but this is marginally useful for people who're clueless about the metadata subsystem and how to go about fixing their problem.

   Smart Folders are similar. If I type "opml" into Finder's search box, it shows me 3 file types: "OPML document", "OPML Podcast File" and "Mellel OPML". These all refer to *.opml files, and while most apps won't understand all of them, it's impossible to keep them apart because (as you noted) apps can't set a file's UTI, and they all use the same file extension.

   So to use a Smart Folder (or Alfred File Filter), I have to add 3 file types/UTIs for it to work as expected. And it will likely stop working properly if I install another app that defines another non-standard UTI for OPML (or whatever).

   The only reliable way to get Smart Folders to work reliably is entering raw queries to ensure that .opml, is the extension, not just contained in the filename. I think this is firmly in power-user territory.

   Markdown presents a similar problem with an added twist. Not only do apps define custom UTIs, there are also a whole bunch of common extensions (.md, .markdown, .mdown).

   Certainly, using org.opml.opml wouldn't solve MMDC's problems with the stupid UTI system, but it would solve some of the issues multiple, non-standard UTIs cause users.

   The one saving grace (sort of) is that the Finder allows you to set a default application for specific documents, and for all documents of a
   specific type.

   In this regard, at least defining net.multimarkdown.opml as being compatible with org.opml.opml would solve the issue of OmniOutliner not being shown as an application that can understand the file format when trying to set it as the default app for .opml files.

   • Edit