Extend AppxManifestReader to support parameter driven filtering

[DrusTheAxe]

Proposal: Extend AppxManifestReader to support parameter driven filtering

Summary

IAppxFactory::CreateManifestReader() returns a manifest reader providing filtered access to the manifest, where this filtering is hardcoded to hide anything newer than the current OS understands. This proposal would provide a functional overload, allowing the caller to specify the namespaces supported with their manifest schemas e.g.

HRESULT CreateManifestReader(
    IStream *inputStream,
    IAppxManifestReaderFilter* filter,
    IAppxManifestReader **manifestReader);

The filter parameter serves 2 purposes:

1. Boolean IsNamespaceKnown(ns)
2. XSD GetXsdForNamespace(ns)

The packaging API could rely on this information from the filter object instead of the hardcoded "Is namespace X known to me? If so, use my hardcoded/embedded XSD for schema validation".

Rationale

The current AppxManifestReader API presumes current-OS == target-OS. This precludes development tools from providing 'cross-compilation' manifest experiences, e.g. validating a manifest how it'll handled on Windows 10.0.12345.0 if the developer's running a version other than 10.0.12345.0 (newer or older results in same, fitlering based on current-OS not the target-OS).

The current behavior also makes it hard for Windows and things like Project Reunion to support newer features on older systems. Any new manifested data won't be visible on older systems, without this caller-driven filtering functionality.

Scope

Capability	Priority
This proposal will allow developers to specify 'known namespaces' to instead of ManifestReader's hardcoded current-OS logic	Must
This proposal will allow developers to specify XSD for 'known namespaces' to instead of ManifestReader using its hardcoded/embedded XSDs	Must

Important Notes

Ideally this would be an extension to the Windows API in appxpackaging.dll

Alternatively this could be provided via the microsoft/msix-packaging API. But...that API is significantly deficient compared to the Windows API in appxpackaging.dll, e.g. bundles aren't supported. Using the msix-packaging API to meet this proposal would require those functional gaps be addressed. It might be viable for some (esp key) scenarios if 'package read' scenarios were fully supported even if 'package write' scenarios had limitations, as most scenarios calling involve reading packages, not writing them.

For related gaps in the microsoft/msix-packaging API see:

• [Feature Request] Provide API via Nuget package #381
• [Feature Request] Provide API via MSIX Framework package #380