The SPI allows registering providers of mime type specific `Lookup`s. The `MimeDataProvider` interface can be used to implement such a provider and register it among the services in the default lookup. The editor/mimelookup module will consult all registered `MimeDataProvider`s when creating a `Lookup` for a specific `MimePath`.

### Default MimeDataProvider

The module itself provides a default implementation of the `MimeDataProvider`, which creates `Lookup`s from the data registered in a hierachical structure of folders on the system filesystem.

The hierarchy starts with the 'Editors' folder and then contains subfolders for each mime type that has some registered objects. Since each mime type is uniquely identified by its `MimePath` the string represantation of the `MimePath` can be used as a filesystem path to the folder holding objects registered for that mime type. For example the 'text/x-java' mime type embedded in the 'text/x-jsp' mime type is represented by the 'text/x-jsp/text/x-java' mime path and the objects/settings specific for this mime type can be registered in the 'Editors/text/x-jsp/text/x-java' folder.

The empty `MimePath` refers to the 'Editors' folder iteslf.

The `Lookup` provided for a mime path is in fact a chain of `Lookup`s for all mime paths that can be created from the original mime path by cutting off its mime type components from the end. So, for example the `Lookup` for the 'text/x-jsp/text/x-java' mime path is made up of three different `Lookup`s using the following folders:

        Editors/text/x-jsp/text/x-java
        Editors/text/x-jsp
        Editors

The default `MimeDataProvider` allows registering implementations of the `Class2LayerFolder` interface in order to supply additional information about the location of instances registered in the mime type folders. Each `Class2LayerFolder` implementation can specify that instances of a certain class will be registered in a special subfolder. The `Lookup` created by the default `MimeDataProvider` will then look into the subfolders rather than to the usual mime type folders when looking for instances of that class. An example can be instances of the `FoldManager` class that are registered in the `foldManager` subfolders. The `Lookup`s hierarchy in this case uses the folders below:

        Editors/text/x-jsp/text/x-java/foldManager
        Editors/text/x-jsp/foldManager
        Editors/foldManager

### Compound MIME types

The default `MimeDataProvider` supports compound mime types, which are the mime types that have two parts separated by a plus sign ('+'). The compound mime types are heavily used for describing different types of XML files. For example an Ant build script's mime type is text/x-ant+xml, which means that the file is an XML file, but not an ordinary XML file. It's a build script.

From the editor's point of view a file with a compound mime type should offer the behavior of the default mime type (e.g. text/xml) plus special behaviors specific for its original mime type (e.g. text/x-ant+xml). Therefore a `Lookup` provided for a mime path that contains a compound mime type will collect settings and services from both the folders belonging to the compound mime type and the folders belonging to its default part. The example below shows the list of folders comprising a `Lookup` for the 'text/x-ant+xml/text/x-java' mime path.

        Editors/text/x-ant+xml/text/x-java
        Editors/text/x-ant+xml
        Editors/text/xml/text/x-java
        Editors/text/xml
        Editors

### Ordering and hiding files

When registering instances in the mime path folders it is possible to use `position` attributes to order the files the same way as you would do it in any other files in a module XML layer. The attributes however will be resolved after all the folders belonging to a mime path are merged. Therefore it is possible to use attributes that define position relatively to a file in a parent (embedding) mime type.

    <folder name="Editors">
      <folder name="Popup">
        <file name="org-openide-actions-CutAction.instance"><attr name="position" intvalue="100"/></file>
        <file name="org-openide-actions-CopyAction.instance"><attr name="position" intvalue="200"/></file>
        <file name="org-openide-actions-PasteAction.instance"><attr name="position" intvalue="300"/></file>
      </folder>
      <folder name="text">
        <folder name="x-java">
          <folder name="Popup">
            <file name="org-netbeans-modules-project-ui-RunSingle"><attr name="position" intvalue="400"/></file>
          </folder>
        </folder>
      </folder>
    </folder>

It is also possible to influence the default inheritance of files from folders belonging to a parent (embedding) mime type and mask them out by defining a 'hidden file' in the child mime type folder. Hidden files are marked by a special attribute called `hidden` with a booleanValue equal to 'true'. The example below hides the editor's global CopyAction in documents with the 'text/x-java' mime type.

    <folder name="Editors">
      <folder name="Popup">
        <file name="org-openide-actions-CutAction.instance" />
        <file name="org-openide-actions-CopyAction.instance" />
        <file name="org-openide-actions-PasteAction.instance" />
      </folder>
      <folder name="text">
        <folder name="x-java">
          <file name="org-openide-actions-CopyAction.instance" >
            <attr name="hidden" booleanValue="true" />
          </file>
        </folder>
      </folder>
    </folder>

Please note that appending '_hidden' to the name of the file does not work, because such a file is made hidden by the XML filesystem implementation when the module layer is loaded and therefore such a file is not visible to the merging mechanism implemented in the mimelookup module.