XSD simplification - Replace PolicySetDefaults / PolicyDefaults / RequestDefaults elements with Defaults

[cdanger]

... or XPathDefaults.

[steven-legg]

If XPath and JSONPath are largely defined in separate profiles then the core has no default settings. However, a future profile might come up with its own useful default settings. The best option may be to have an empty <Defaults> element and DefaultsType base type, allow a list of <Defaults> elements in a policy and a request, and leave the profiles to extend DefaultsType and <Defaults> element in a separate namespace to convey what they need.

In the core:

<xs:element name="Defaults" type="xacml:DefaultsType" abstract="true"/>
<xs:complexType name="DefaultsType" abstract="true"/>

In PolicyType and RequestType:

<xs:element ref="xacml:Defaults" minOccurs="0" maxOccurs="unbounded"/>

In the XPath profile:

<xs:element name="XPathDefaults" type="xacml-xpath:XPathDefaultsType" substitutionGroup="xacml:Defaults"/>
<xs:complexType name="XPathDefaultsType">
  <xs:complexContent>
    <xs:extension base="xacml:DefaultsType">
      <xs:attribute name="XPathVersion" type="xs:anyURI" use="required"/>
    </xs:extension>
  </xs:complexContent>
</xs:complexType>

[steven-legg]

In PolicyType and RequestType:

<xs:element ref="xacml:Defaults" minOccurs="0" maxOccurs="unbounded"/>

We could also split that with PolicyDefaults in PolicyType and RequestDefaults in RequestType, where PolicyDefaults and RequestDefaults are empty extensions of Defaults.

[cdanger]

OK, agreed to keep separate RequestDefaults and PolicyDefaults in case some profile wants to have different definitions for both.

<xs:element name="RequestDefaults" type="xacml:DefaultsType" abstract="true"/>
<xs:element name="PolicyDefaults" type="xacml:DefaultsType" abstract="true"/>
<xs:complexType name="DefaultsType" abstract="true"/>

Then in the XPath profile, I can still have the same type definition for both:

<xs:element name="XPathRequestDefaults" type="xacml-xpath:XPathDefaultsType" substitutionGroup="xacml:RequestDefaults"/>
<xs:element name="XPathPolicyDefaults" type="xacml-xpath:XPathDefaultsType" substitutionGroup="xacml:PolicyDefaults"/>

<xs:complexType name="XPathDefaultsType">
  <xs:complexContent>
    <xs:extension base="xacml:DefaultsType">
      <xs:attribute name="XPathVersion" type="xs:anyURI" use="required"/>
    </xs:extension>
  </xs:complexContent>
</xs:complexType>

(In XSD 1.1, this could be simplified further since we can have multiple QNames in the substitutionGroup:

<xs:element name="XPathDefaults" type="xacml-xpath:XPathDefaultsType" substitutionGroup="xacml:RequestDefaults xacml:PolicyDefaults"/>
...

But I'm not sure we should migrate to XSD 1.1 just yet ;-) considering the lack of support in open source tools. Food for thought.
)

Also I'm thinking that some PDP (e.g. AuthzForce) may be able to receive both XML and JSON inputs in the same request, e.g. JSON content in the subject category and XML content in the resource category, in which case we would need 2 types of RequestDefaults elements in the same Request (or 2 PolicyDefaults in a policy) :

<Request>
<JsonRequestDefaults>...</JsonRequestDefaults>
<XPathRequestDefaults>...</XPathRequestDefaults
...
</Request

In general we might have more than one Request/PolicyDefaults elements (one per profile used), which changes the number of occurrences of Defaults in RequestType/PolicyType a bit (maxOccurs="unbounded").

[steven-legg]

In general we might have more than one Request/PolicyDefaults elements (one per profile used), which changes the number of occurrences of Defaults in RequestType/PolicyType a bit (maxOccurs="unbounded").

I had maxOccurs for the Defaults element ref originally, so I agree.

[steven-legg]

But I'm not sure we should migrate to XSD 1.1 just yet ;-) considering the lack of support in open source tools.

Well, let's not do it then.