I can follow the DXA documentation on how to map multiple Schemas to a single entity and how such mappings generate markup for you.

Questions on the mappings:

  1. If we wanted to represent content as different "types" we would create different Schemas, right?
  2. Is the documentation example RDFa? Could an implementer change the Microdata Language (say to Microdata per below)?

Example RDFa from Schema.org (Event):

<div vocab="http://schema.org/" typeof="Event">
  <a property="url" href="nba-miami-philidelphia-game3.html">
  NBA Eastern Conference First Round Playoff Tickets:
  <span property="name"> Miami Heat at Philadelphia 76ers - Game 3 (Home Game 1) </span>

Microformat, also from Schema.org:

<div itemscope itemtype="http://schema.org/Event">
  <a itemprop="url" href="nba-miami-philidelphia-game3.html">
  NBA Eastern Conference First Round Playoff Tickets:
  <span itemprop="name"> Miami Heat at Philadelphia 76ers - Game 3 (Home Game 1) </span>

2 Answers 2


If we wanted to represent content as different "types" we would create different Schemas, right?

Not necessarily. It is possible to have multiple view models for a single schema each of which represents a different semantic entity. I guess typically you would have different schemas, but there may be scenarios where to avoid schema bloat in the CMS you have more generic schemas.

To take your schema.org Event example, you might want to have a single CMS schema for Events but actually want to have different semantic types on your site (Festival, SportsEvent, BusinessEvent) each with a different view to render the content differently.

Key to this is of course the relationship between model and view (which has direct parallels in the relationship between Schemas and Component Templates in the CMS). We want to render the content with a certain view. A mapping is defined from view to model, and thus we convert the CMS model into this view model.

Is the documentation example RDFa? Could an implementer change the Microdata Language (say to Microdata per below)?

Like Rick says, you can take control of the format used for semantics by implementing your own helpers to replace the built in ones on @Html.DxaEntity/Property or @Markup.Entity/Property (older DXA versions).


It might be worth adding a bit of background on the thinking behind DXA supporting almost arbitrary N->M schema->view model mappings. Many MVC implementations I have worked on enforce a 1-1 mapping between schemas and view models, however I have found that you can come unstuck in these scenarios. Some typical issues I have seen are:

  1. Efficiency - My Article schema has 40 fields, but in my Article Summary view, I want to render the title, summary and image and a resolved link. In my Article Details view I want to render all 40 fields, but no resolved link. Having a single model for both is not optimal for either. In DXA we can easily create a simple ArticleSummary model with a resolved link, and a full Article model without the resolved link.

  2. Reuse - Actually its not only articles that I want to render on the site with my Summary view (title, summary, image, link) - I want to reuse this view (and model) for rendering Events, Blog Posts, Products. In DXA this is simple (Teaser is a good example of this)

  3. Performance - My Product schema contains some marketing content, which I enrich with pricing and availability from my eCommerce system, and technical data from a PIM system before rendering with a Product Details view. However I also want to provide the marketing content only in a lightweight JSON format to a fancy AJAX driven Product Carousel on my site. In DXA I can easily create a Product model for the Product Details View containing all data loaded from the 3 systems, and a lightweight ProductSummary model for the JSON, which contains only the required content, ensuring the model can be more quickly loaded and bandwidth to the browser (and resources it requires to parse/process the content) are optimized

  • Excellent background, Will. If we use, say, a single Event schema for other semantic types, what would create the relationship? A CMS template selection? Or maybe Component metadata to the "context" of the Page? Mar 24, 2016 at 9:54
  • 1
    Component Templates are linked to MVC Views by metadata, and there is a mapping from View to View Model in the DXA web application. Thus your schema is linked to the view model via CT and View.
    – Will Price
    Mar 24, 2016 at 11:07
  • Note you can quite easily override the mapping from CT to view. I have done this on non-DXA projects where we used a combination of CT metadata (base view) and component field (ContentType - a select list of predefined content types) to define the view.
    – Will Price
    Mar 24, 2016 at 11:09
  1. Indeed, CM Schemas act as Content Types (have to be careful with terminology here, because XPM also uses that term for something which is a bit more than only a Schema).

  2. The DXA framework has built-in support for generating RDFa attributes, which are standard in HTML 5. If you prefer to use legacy microformats, you will have to output the attributes yourself in your Views or use your own helpers instead of @Html.DxaRegion/Entity/PropertyMarkup.

To elaborate on mapping multiple CM Schemas to the same View Model type: frankly, I can't come up with good use cases for doing so. The DXA Core does this for Teasers, but that's on our backlog to improve. It would be cleaner to let Teaser be an interface which can be implemented by multiple distinct View Model types.

  • I think you can draw a nice parallel with wanting to map different schemas to the same view model with the ability in the CMS to link a Component Template to multiple schemas. The use case there is pretty much the same.
    – Will Price
    Mar 24, 2016 at 8:01
  • What would be the advantage of having Teaser as an interface? It seems to me this means that you just need to define a different (identical) model for each schema that you want to leverage as teasers in your site, which seems like unneeded code duplication.
    – Will Price
    Mar 24, 2016 at 8:06
  • The disadvantage of mapping multiple Schema to a Teaser View Model type is that is not extensible; if you want to map additional Schema, you have to modify the Teaser type (which is part of the DXA Core). Of course you could do the mapping on CM-side, but we currently don't have user-friendly support for that yet. Mar 24, 2016 at 18:40
  • You could make the same point about any model that comes OOB. I think in most serious implementations, you are going to create your own schemas, models and views, as such perhaps the models should be moved out of the core - I think that they, much like the views serve more as a good example, and give you something to do a quickstart with little or no coding.
    – Will Price
    Mar 29, 2016 at 7:13
  • The problem with the Teaser type is that it's currently more than an example; it's integral part of the framework because it is used in framework APIs (IContentProvider in particular). Mar 29, 2016 at 17:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.