Update IntelliSense XSD to support multiple metadata representations

[rainersigwald]

You can represent item metadata either as subelements or as attributes of the item XML element. The XSD should provide equivalent IntelliSense for both (but doesn't today, because in XSD the representations are distinct).

[drewnoakes]

There's also duplication (and IIRC inconsistent replication) of metadata across different item types (Compile, EmbeddedResource, Content, Page, Resource, ApplicationDefinition, None).

It might make sense to introduce a new type in the schema to represent common metadata for items that represent files in the project, including Link, Visible, CopyToOutputDirectory, etc.

[rainersigwald]

It might make sense to introduce a new type in the schema to represent common metadata for items that represent files in the project, including Link, Visible, CopyToOutputDirectory, etc.

Do you know offhand how to represent that in XSD? If not no need to look it up or anything, just checking :)

I wonder if we may be able to use this to solve another issue we have which is that the XSDs are localized in the VS repo because there wasn't any tooling support for XSD localization in public at the time we open-sourced. But if the XSD was a generated artifact we could pull from standard loc infra XLF.

Of course the real fix is #1774 or https://github.com/mhutch/MonoDevelop.MSBuildEditor, so maybe we shouldn't overengineer this.

[drewnoakes]

Do you know offhand how to represent that in XSD?

The code that inspired the idea is the definition of SimpleItemType in Microsoft.Build.Core.xsd:

msbuild/src/MSBuild/MSBuild/Microsoft.Build.Core.xsd

Lines 415 to 454 in 2b604c3

	<!-- ======================================================================================= -->
	<xs:element name="Item" type="msb:SimpleItemType" abstract="true"/>
	<!-- ======================================================================================= -->
	<!-- convenience type for items that have no meta-data-->
	<!-- note this allows Remove or no attribute instead of Include, which is too lax outside of Targets at present, but
	it's the best we can reasonably do with an XSD -->
	<xs:complexType name="SimpleItemType">
	<xs:attribute name="Condition" type="xs:string" use="optional">
	<xs:annotation>
	<xs:documentation><!-- _locID_text="SimpleItemType_Condition" _locComment="" -->Optional expression evaluated to determine whether the items should be evaluated</xs:documentation>
	</xs:annotation>
	</xs:attribute>
	<xs:attribute name="Include" type="xs:string" use="optional">
	<xs:annotation>
	<xs:documentation><!-- _locID_text="SimpleItemType_Include" _locComment="" -->Semi-colon separated list of files (wildcards are allowed) or other item names to include in this item list</xs:documentation>
	</xs:annotation>
	</xs:attribute>
	<xs:attribute name="Exclude" type="xs:string" use="optional">
	<xs:annotation>
	<xs:documentation><!-- _locID_text="SimpleItemType_Exclude" _locComment="" -->Semi-colon separated list of files (wildcards are allowed) or other item names to exclude from the Include list</xs:documentation>
	</xs:annotation>
	</xs:attribute>
	<xs:attribute name="Remove" type="xs:string" use="optional">
	<xs:annotation>
	<xs:documentation><!-- _locID_text="SimpleItemType_Remove" _locComment="" -->Semi-colon separated list of files (wildcards are allowed) or other item names to remove from the existing list contents</xs:documentation>
	</xs:annotation>
	</xs:attribute>
	<xs:attribute name="Update" type="xs:string" use="optional">
	<xs:annotation>
	<xs:documentation><!-- _locID_text="SimpleItemType_Remove" _locComment="" -->Semi-colon separated list of files (wildcards are allowed) or other item names to be updated with the metadata from contained in this xml element</xs:documentation>
	</xs:annotation>
	</xs:attribute>
	<xs:attribute name="Label" type="xs:string" use="optional">
	<xs:annotation>
	<xs:documentation>
	<!-- _locID_text="ImportGroupType_Label" _locComment="" -->Optional expression. Used to identify or order system and user elements
	</xs:documentation>
	</xs:annotation>
	</xs:attribute>
	</xs:complexType>

That definition is then used in Microsoft.Build.CommonTypes.xsd via the base attribute, as per this example for Compile items:

msbuild/src/MSBuild/MSBuild/Microsoft.Build.CommonTypes.xsd

Lines 695 to 701 in 2b604c3

	<xs:element name="Compile" substitutionGroup="msb:Item">
	<xs:annotation>
	<xs:documentation><!-- _locID_text="Compile" _locComment="" -->Source files for compiler</xs:documentation>
	</xs:annotation>
	<xs:complexType>
	<xs:complexContent>
	<xs:extension base="msb:SimpleItemType">

The intermediary level would likely need both a name and base.

[Forgind]

Is the goal here just to make the two representations have the same content, or is it to use the base types so you only have to specify metadata valid for a particular item type in one place? The latter seems nicer, but it doesn't sound doable from what I see here; you can specify a base type that applies the same thing to everything that uses it, but if we have a specific set of things to add as metadata for an item, only that item would be able to extend the base type, so you haven't gained anything. The annotations and subelements have different formats, so you also can't replicate between the two of them. Am I missing something?

[rainersigwald]

The two representations are equivalent in MSBuild and should be equivalent in the intellisense. Making them have the same representation in the XSD would be nice. But I don't think it's required--we could instead make the canonical checked-in representation some other thing and generate an XSD with the correct doubling.

[Forgind]

That's an interesting idea and sounds very doable...but also much more like a BenVillalobos project than something for me 😉