Office-js-docs-pr: Not clear where manifest Requirements element goes or how to specify Word 2016 or above

[paulwib]

In this article it doesn't mention where the <Requirements> element goes in the manifest. The Requirements element docs say it should be "Contained in" <OfficeApp> but when I do that and run it through the office-toolbox validator it says <Requirements> is not allowed as a child of <OfficeApp>, with the error:

XML Schema Violation: Your manifest does not adhere to the current set of XML schema definitions for Office Add-in manifests. (link: https://aka.ms/add-in-manifest-schema-violation)
  - Details: The element 'OfficeApp' in namespace 'http://schemas.microsoft.com/office/appforoffice/1.1' has invalid child element 'Requirements' in namespace 'http://schemas.microsoft.com/office/appforoffice/1.1'. List of possible elements expected: 'Dictionary' in namespace 'http://schemas.microsoft.com/office/appforoffice/1.1' as well as 'VersionOverrides' in namespace 'http://schemas.microsoft.com/office/taskpaneappversionoverrides' as well as any element in namespace 'http://www.w3.org/2000/09/xmldsig#'.

I was able to get it to validate by moving it to the VersionOverrides section and flip some namespace bits:

<OfficeApp xmlns="http://schemas.microsoft.com/office/appforoffice/1.1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xmlns:bt="http://schemas.microsoft.com/office/officeappbasictypes/1.0" xmlns:ov="http://schemas.microsoft.com/office/taskpaneappversionoverrides"
  xsi:type="TaskPaneApp">
  ...
  <VersionOverrides ...>
   ...
    <!-- Set required version of OfficeJS API -->
    <Requirements>
      <Sets xmlns="http://schemas.microsoft.com/office/officeappbasictypes/1.0">
        <Set Name="AddinCommands" MinVersion="1.1" />
        <Set Name="WordApi" MinVersion="1.1" />
      </Sets>
    </Requirements>
  </VersionOverrides>
</OfficeApp>

That passes validation, but it still says the app will be tested against Word 2013, despite the requirements not being supported by Word 2013 - specifically AddInCommands. This was the validator output:

Validation: Passed
Based on the requirements specified in your manifest, your add-in can run on the following platforms; your add-in will be tested on these platforms when you submit it to the Office Store:
  - Word for iPad
  - Word 2016 for Mac
  - Word Online
  - Word 2013 or later
  - Word 2016 or later
Important: This analysis is based on the requirements specified in your manifest and does not account for any runtime JavaScript calls within your add-in.

So, is there a way to use this to specify a Word Add-in only supports 2016 or above? Or do we have to use runtime checks?

---

Document details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 1b7148f0-0384-00d9-16f4-99cdab9c8ecc
• Version Independent ID: 9a7623fd-dd24-267f-a17f-dfcbd496ee0e
• Content: Specify Office hosts and API requirements - Office Add-ins
• Content Source: docs/develop/specify-office-hosts-and-api-requirements.md
• Product: non-product-specific
• GitHub Login: @o365devx
• Microsoft Alias: o365devx

[Rick-Kirkham]

@paulwib That error can mean that the element is simply in the wrong order relative to its peers in the parent element. Ideally our reference for manifest elements should specify this. In the meantime, we've provided this article: Manifest element ordering. Please see if it helps.

[paulwib]

Thanks @Rick-Kirkham, very useful article. Couldn't quite follow the XSD, but figured out the right sequence by trial and error :)

For me the solution was to put the Requirements element after the Hosts element (both children of OfficeApp).

[akoushke]

@Rick-Kirkham as @paulwib mentioned, the documentation is not clear on where to declare the requirement tag. a simple example would resolve all of these confusions.

[akoushke]

For me the solution was to put the Requirements element after the Hosts element (both children of OfficeApp).

That's what I needed. Thanks @paulwib

[Rick-Kirkham]

@akoushke We realize our documentation about the sequence of the elements is not as good as it could be. There is a possibility that the XSD will be changed so that the order doesn't matter. Until that decision is made one way or the other, we don't want to invest time documenting the order.