Asset Type Computation Is Inconsistent
Describe the bug The asset type computed by AssetTypeImpl is inconsistent due to the way it's implemented. The extension is extracted as the last part of the dc:format property, some examples:
- xxx.mpg: video/mpeg, extension = MPG
- xxx.ppt: application/vnd.ms-powerpoint, extension = vnd.ms-powerpoint
- xxx.png: image/png, extension = png
- xxx.mp4: video/mp4, extension = MP4
This value is then checked against the mimetype lookup provided by Adobe: /libs/dam/gui/content/assets/jcr:content/mimeTypeLookup
In short: the extension is checked against an array of mimetypes for the childnodes of this specific lookup node to determine the asset type.
There is however a type in AEM 6.4 (checked on 6.4.7) where every last value of the mimetype property of these childnodes has a ; dangling.

Since the UIHelper in the code splits on ,, the last value to compare the extension to will never match. Applied to the examples:
- xxx.mpg: matches with value in Multimedia node, resulting in asset type = MULTIMEDIA
- xxx.ppt: Doesn't match anything since extension = vnd.ms-powerpoint is not a real extension included in the lookup node implementation by Adobe.
- xxx.png: matches with Image node
- xxx.mp4: should match with Multimedia node (same as mpg) BUT, since their is the dangling
;to the MP4 entry in the mimetype property, it actually fails the compare check. Hence, this asset type will be decided by the if else cases, resulting in: asset type = VIDEO
Since this value is used to resolve the details page for a specific asset, this results in different behaviour for 2 asset of same mimetype, which should have asset type: video:
- the xxx.mpg asset will link to details/multimedia.html -> doesn't exists: resolves to default details page: undesired behaviour
- the xxx.mp4 asset will link to detaills/video.html -> exists: desired behaviour
In AEM 6.5 (checked 6.5.6), this dangling ; is removed however, meaning the MP4 assets will also match MULTIMEDIA in the lookup node, meaning the MP4 assets will not resolve to the details/video.html Asset Share details page anymore.

Environment
- AEM Version: 6.5.6
- Asset Share Commons Version: 1.9.4
- Author, Publish or both? Publish (Asset Share details page resolving)
Current Impact
- on 6.4: MPG, WAV etc assets don't resolve to the same Asset Share details page as eg MP4 (due to the
;) or MOV (dc:format= video/quicktime, which is determined by the if/else cases) assets - on 6.5: MPG, WAV, MP4 etc assets will not resolve to details/video.html on Asset Share while MOV will (dc:format= video/quicktime, which is determined by the if/else cases) assets
Expected behavior 2 assets (video's) should resolve to the same details page and asset type should be determined in a consistent way. I believe the type selection should not depend on the AEM libs nodes:
- not all extensions are included in the lookup node, eg xxx.ppt where the extension according to the code is
vnd.ms-powerpoint. Hence this asset type is determined by the if/else cases. This makes Asset Type selection inconsistent. - creates a dependency on an AEM libs node while the behaviour for resolving asset share details pages based on an asset type is Asset Share Commons specific (any change to the lookup node might have undesired impact on Asset Share).
The Asset Type should be only be determined by the if/else cases to result in expected behaviour. Extra mapping by OSGi config could allow more complex/exception Asset Type computation
@thmsdbts I agree. Some background, we were trying to keep Asset Share Commons UI consistent with AEM Assets UI. We would welcome a PR that improves this. Another approach is also to extend the Asset Type computed property: https://adobe-marketing-cloud.github.io/asset-share-commons/pages/development/guide/ -> Extend Computed Properties
You can also create a new AssetDetailsResolver [1] impl (examples: [2]), which will automatically show up as an option on the Search Page's configuration [3]) and you can use that to pick the details page. The Asset Details page resolution was designed to be pluggable since we knew different people would want different approaches (breaking it out by "file type" is very generic use case).
[1] https://github.com/Adobe-Marketing-Cloud/asset-share-commons/blob/develop/core/src/main/java/com/adobe/aem/commons/assetshare/configuration/AssetDetailsResolver.java [2] https://github.com/Adobe-Marketing-Cloud/asset-share-commons/blob/develop/core/src/main/java/com/adobe/aem/commons/assetshare/configuration/impl/selectors/AssetTypeSelectorImpl.java [3] https://adobe-marketing-cloud.github.io/asset-share-commons/pages/search/search-page/