Purpose of new MSIX manifest schema additions?

[Sunburst]

I am running the Windows Insider Preview, build 20175.1000. I have found some new, as-yet-undocumented MSIX manifest schemas, and I was wondering if anyone might have any insight into what they might be useful for. (To follow along, install Resource Hacker and open the file C:\Windows\System32\AppxPackaging.dll; the schemas are found under the "500" entry in the list on the left.) Since these features are still in early beta, I thought it would be better to post here instead of filing a GitHub issue on the MSIX schema reference on docs.microsoft.com.

"Manganese" Cloud Files Schema (#162)

These elements seem to duplicate the functionality of the existing windows.cloudFiles extension in desktop3. I'm not certain why we need two.

"Iron" desktop7 Schema (#164)

Why, exactly, are there MSIX entries to create new items in the Control Panel shell namespace? After all, the legacy Control Panel is deprecated in favor of the UWP-based Settings app. While the Settings app is currently not extensible by third parties, there is little reason (that I know of) that the Control Panel entries in this schema would be incompatible with the Settings app, since all they can do is provide a link to an external application. Nonetheless, Microsoft has given no evidence that they will be migrating the ability to add new items to the legacy Control Panel into the Settings app.

"Manganese Preview" COM support (#501)

This appears to be a superset of the com:, com2:, and com3: schema namespaces. Is there a reason why we cannot simply extend those schemas, instead of having to duplicate everything?

"Manganese Preview" MSIX App Compat Support (#503)

This schema defines an extension for creating custom shortcuts, an apparent duplicate of rescap3:DesktopAppMigration, an extension for registering MAPI handlers, and finally, an extension for creating Windows 7-style application registrations. This last one is weird, because (a) the UI that consumes this kind of application registration has been removed (when you click on it in Control Panel, it simply opens the Settings app, which uses a different UI that does not surface the same information as its Windows 7 equivalent), and (b) MSIX already does this registration for you.

"Iron Preview" MSIX App Compat Support (#504)

This schema contains a system error reporting extension (which is self-describing), and what appears to be a subset of the file association support present in several of the existing schemas. Again, why do we need two, especially since this one has fewer features than what is present in the already documented schemas?

Thanks for looking into this for me!

[#2]

@Sunburst 

I, too, find the schemas frustrating and wish to add my thoughts.  Although I don't expect that Microsoft would respond to requests regarding the undocumented pieces, we can still vent about the state of the schemas.

I am so far avoiding any programing that requires me to generate or parse the manifest, because it is impossible to create a validator for the available schemas.  The practice of adding additional schema files each release, in combination with what I think of as different schema families (what you want for iot or mobile is a different subset of similar things), has led to elements and parameters defined without the logic about where these things belong.

Microsoft code itself must be littered with assumptions about what are legal combinations (or placements of elements in the XML) that outsiders can only guess at because quite too often it is not defined in the schema sets.  As an example, last year I looked into ApplicationAlias. It was a well defined element in itself, but at the time I was unable to find any element with documentation/schema that accepted it as a sub-element.  We are left to searching for examples where Microsoft actually is seen using it to understand a possible usage structure.

If Microsoft wants a robust partner environment I believe that they are going to have to clean this up at some point. 

[#3]

Hey folks,

Thanks for the detailed feedback on the manifest schemas.

We understand your concerns about the state of documentation around manifest schemas and the impact this has on our partners.

We are working out what additional details we can provide and hope to create a more detailed post explaining the overall rational and design of the manifest schemas.

Thanks!

James