Should we allow FeatureFlag.enabled to be "true"/"false" (string type)?

[Eskibear]

Given FeatureFlag.enabled is defined as boolean type in the schema, is it proper to support "true"/"false" of string type, especially in official samples?

Schema:

AppConfiguration/docs/FeatureManagement/FeatureFlag.v2.0.0.schema.json

Lines 43 to 46 in d0ef7d5

	"enabled": {
	"$id": "#/properties/enabled",
	"type": "boolean",
	"title": "Enabled State",

Samples:

AppConfiguration/docs/FeatureManagement/Samples/NoFilters.sample.json

Lines 21 to 35 in d0ef7d5

	"id": "StringTrue",
	"description": "A feature flag with no Filters where enabled is a string, that returns true.",
	"enabled": "true",
	"conditions": {
	"client_filters": []
	}
	},
	{
	"id": "StringFalse",
	"description": "A feature flag with no Filters where enabled is a string, that returns false.",
	"enabled": "false",
	"conditions": {
	"client_filters": []
	}
	},

[zhenlan]

Looks like an oversight in the samples.

[mrm9084]

These were added as we don't say we support String. But all of our libraries support Strings.

[zhenlan]

Implementation for different platforms can vary, sometimes, for compatibility reasons, but the official samples shouldn't violate the schema.

[jimmyca15]

@mrm9084 can you take the fix for this?

[mrm9084]

I have it fixed locally, just haven't got the PR up yet. Was trying to finish something else first.

[mrm9084]

Fixed in this PR #923