Page tree
Skip to end of metadata
Go to start of metadata


Overview of the current DAM implementation and open Issues/Questions.


Existing documentation

Concepts to clarify


AssetProvider assembles the DamAsset based on the asset node from the workspace and the related DAM asset.

  • Sets the Meta-Data source which allows for flexible changing the ways of how meta-data is fetched and from where (typically - from the asset node internals, but could be from wherever).

Stored informations on an Asset:

  • mgnl:asset language    Asset.getLanguage() --> returned type: String or Local ?
  • mgnl:asset name          Asset.getName()
  • mgnl:asset title             Asset.getTitle()
  • mgnl:asset type            ???
  • mgnl:asset subject        Asset.getSubject()
  • mgnl:asset description  Asset.getDescription()
  • mgnl:asset  caption       Asset.getCaption()
  • mgnl:asset  copyright    Asset.getCopyright()
    • jcr:content extension           Asset.getFileExtension()
    • jcr:content  fileName           Asset.getFileName()
    • jcr:content  height                Asset.getHeight()
    • jcr:content  size                   Asset.getSize()
    • jcr:content  with                   Asset.getWith()
    • jcr:content  jcr:data              Asset.getBinaryData()
    • jcr:content  jcr:mimeType    Asset.getMimeType

Information stored in the Meta-Data content node (these are the optional properties that a content node can have)


  1. mgnl:asset attributes are not exposed by the Asset Implementation (language/title/...). Is this correct?
  2. Meta-Data: Should we keep the concept of a MetaData object?
    1. copyright is this not a Asset attribute ?
    2. how to handle duplicate (title/description) defined on Asset and Meta-Data ?
  3. Should we introduce a concept of CopyRight ?

Get meta-Data from DAM asset, and override it if existing on the content node.


Remove the Meta-Data concept.
Add caption and copyright properties under asset Node.
It will be to responsibility of modules using DAM to override these properties if they come from another place (STK, textImage model class)

Asset Node Type

Current DAM workspace hierarchy structure:

Open Issues/Questions:

  1. Version: How to handle versions?
  2. For external provider we said that we should at least have one DAM Node pointing to the external Content (binary) but
    the current  mgnl:asset required a mgnl:resource  with a jcr:data (type="Binary")
    Should we introduce a new type for external Content ?
    In addition from previous concept page:
    1. 'Although assets could come from different sources, the asset node will have standard fields that will enable it to be displayed in lists etc'
    2. 'AssetNode has a field specifying assetProviderType'Not Implemented
  3. For multivariant assets (i18n-ed, multiple sizes etc.) it might support multiasset.


(mgnl:multiasset) this way we could potentially group assets that should be presented as one within Magnolia, but still allow each variant to keep own set of properties and be indexed separately.

Still How to handle version?


Keep the current JCR structure.
MultiAsset, ExternalAsset will be better defined in another SPRINT.

Asset Provider functionalities

Extend the Asset provider functionalities:

  • getAssets(Node, String)  List<DamAsset> : If the Identifier refer to a DAM folder, return the list of child assets
  • getAssetVersion(...)

General questions

  • In previous STK/DMS collaboration - link to a document can be a path or a Identifier. Do we support path?
  • Currently in info.magnolia.dam.asset,  there are Asset, DamAsset, and DamAssetWrapper (And considering there is no more metadata)
    (Im not talking about stk AssetWrapper here)
    • Do we really need Asset and DamAsset - why, is this just an artifact from DMS?
    • What is the value of DamAssetWrapper


Only support Identifier link to DAM.
Review the current DAM API

  • Remove DamAssetWrapper
  • Rename DamAsset to InternalAsset

Open Questions/Tasks

Links (related to MGNLSTK-1048 issue)

Create a  DAMURI2RepositoryMapping extends URI2RepositoryMapping (Equivalent of DMSURI2RepositoryMapping)  

Create a DAMDownloadServlet (Equivalent of DMSDownloadServlet)

These two class should use the DAM class to get the correct AssetProvider. The AssetProvider should expose a method getLink(damNode) --> String tha return the correct Link based on the source storage (dam workspace, webdav...)

API review

DamAsset ? should we keep this class?

Should we create an equivalent of DMS document?

Should we remove or deprecated all STK dam package?

STKImagingSupport should use only STKTemplatingFunction to create Link for Binary content and not TemplatingFunction.

In STK for model class that use previously DMS, we expose a method that return the target as ContentMap. This content map is the representation of a JCR node.
  How to handle external source ?
    Should we return an Asset object instead? --> review and migrate FTL's

  • Taken approach : Deprecate old methods. Expose a new method returning an Asset. 


STK Model still expose method like getDMSDocument. Should we rename these methods --> review and migrate FTL's.



type key summary assignee reporter priority status resolution created updated due

Unable to locate Jira server for this macro. It may be due to Application Link configuration.

  • No labels


  1. It is probable relevant to note that Magnolia uses the Dublin Core Meta Data standard. This should be kept. Optimally it should be possible to use different meta data sets like IPTC or EXIF for images; maybe using mixins to allow that? For an overview of (some) meta data standards, see

    1. We are tacking this into account. We will at least support the Dublin Core Meta Data standard that is in fact no more the case as the specification was updated in 2012.

      A new user story was created and also a new concept page Concept - DAM Dublin Core MetaData.