Reduce the XML attribute names of PolicyId, RuleId, VariableId, etc. to just Id.

[steven-legg]

There's no problem renaming the PolicyId, RuleId, ShortIdSetId, VariableId and AttributeId XML attributes to just Id for Policy, Rule, ShortIdSet, VariableDefinition and Attribute, respectively, but it does highlight a lack of consistency in the way those constructs are referenced by identifier.

The new PolicyReference uses Id; Function and Apply use FunctionId; VariableReference uses VariableId; RuleCombinerParameters uses RuleIdRef; PolicyCombinerParameters uses PolicyIdRef; AttributeDesignator, AttributeAssignment, AttributeAssignmentExpression and MissingAttributeDetail use Category and AttributeId; and AttributeSelector uses Category and ContextSelectorId.

I've included Category in there because there has been a proposal to rename Attributes to Category (as in the JSON REST Profile), which would create a case for renaming its Category XML attribute to CategoryId or Id. That would affect things like AttributeDesignator that have a Category attribute and an AttributeId attribute. It can't have two XML attributes called Id. I wouldn't recommend using Category and Attribute as the XML attribute names because that creates instances of the one name with two different types. In XML one would be an element and one would be an XML attribute but JSON wouldn't have that distinction. That leaves CategoryId and AttributeId as the XML attribute names for AttributeDesignator and the like.

Elements that only reference one kind of thing, such as PolicyReference and VariableReference can get away with just using Id but then that is inconsistent with AttributeDesignator. Using the same XML attribute name for both the identifying and referencing cases (e.g., PolicyId, AttributeId, RuleId) has an elegant uniformity despite the extra length. If you see PolicyId it is always the identifier for a policy. Id could be the identifier for a number of things depending on the context.

Regardless, PolicyIdRef and RuleIdRef don't need the "Ref" on the end and Function ought to be renamed to FunctionReference to be consistent with VariableReference and PolicyReference.

Having mentioned Function and VariableReference, they are verbose in the JSON example policies:

"Function":{
  "FunctionId":"anyURI-equal"
}

"VariableReference":{
  "VariableId":"17590034"
}

They have to be complex types in the XSD because they are in the Expression substitution group. It would be nice to translate any complex type with only a single XML attribute into just a member (and bypassing the longer Id names, though breaking uniformity):

"FunctionReference":"anyURI-equal"

"VariableReference":"17590034"

Using the single XML attribute name instead of the element name would work too, though it feels a bit NQR:

"FunctionId":"anyURI-equal"

"VariableId":"17590034"