Add normative parts of the Entities Profile to the core for XACML 4.0.

[steven-legg]

I would like to see at least the XSD for the Related and Nested Entities Profile as part of the core specification for XACML 4.0, if not the normative text as well. XML Schema allows multiple files for a namespace, but it is unconventional and awkward. I haven't looked into JSON Schema to see how it deals with types defined across multiple files. I'm okay with the profile's informative discussion and examples being a separate document.

A separate question is the conformance level of any included definitions. I will defer to @cdanger on that since he would have a lot more to implement than me if it is made mandatory.

The profile's EntityType doesn't need to be normative, but it is practically a base type for AttributesType:

<xs:complexType name="EntityType">
  <xs:sequence>
    <xs:element ref="xacml:Content" minOccurs="0"/>
    <xs:element ref="xacml:Attribute" minOccurs="0" maxOccurs="unbounded"/>
  </xs:sequence>
</xs:complexType>

<xs:complexType name="AttributesType">
   <xs:complexContent>
          <xs:extension base="xacml:EntityType">
              <xs:attribute name="CategoryId" type="xs:anyURI" use="required"/>
              <xs:attribute ref="xml:id" use="optional"/>
          </xs:extension>
   </xs:complexContent>
</xs:complexType>

I don't see a compelling reason for the XACML attributes in EntityType to have the IncludeInResult XML attribute.

[humantypo]

I like the idea of including the Profile in the core spec given it's purpose.

[cdanger]

I would like to see at least the XSD for the Related and Nested Entities Profile as part of the core specification for XACML 4.0, if not the normative text as well. XML Schema allows multiple files for a namespace, but it is unconventional and awkward.

OK for me, it makes sense to merge the Profile's XSD into the core spec (especially the EntityType).

I haven't looked into JSON Schema to see how it deals with types defined across multiple files. I'm okay with the profile's informative discussion and examples being a separate document.

The JSON part could make it in the (future) JSON Profile of XACML 4.0 which should have a JSON schema for requests and responses (and possibly for the policies according to issue #7 ).

A separate question is the conformance level of any included definitions. I will defer to @cdanger on that since he would have a lot more to implement than me if it is made mandatory.

I'm OK with making these mandatory, i.e. the Profile's new datatype / quantified expressions / functions (except attribute-selector as said in the Conformance section). Our implementation does not support it yet, but I am willing to add this to the roadmap.

The profile's EntityType doesn't need to be normative, but it is practically a base type for AttributesType:

<xs:complexType name="EntityType">
  <xs:sequence>
    <xs:element ref="xacml:Content" minOccurs="0"/>
    <xs:element ref="xacml:Attribute" minOccurs="0" maxOccurs="unbounded"/>
  </xs:sequence>
</xs:complexType>

<xs:complexType name="AttributesType">
   <xs:complexContent>
          <xs:extension base="xacml:EntityType">
              <xs:attribute name="CategoryId" type="xs:anyURI" use="required"/>
              <xs:attribute ref="xml:id" use="optional"/>
          </xs:extension>
   </xs:complexContent>
</xs:complexType>

I like the idea of using EntityType as the base type in the core schema. But in that case, the name AttributesType does not make sense to me anymore since the EntityType itself has Attributes so could be called AttributesType as well. The main additional thing of AttributesType is the category, therefore renaming AttributesType to CategorizedEntityType would make more sense I think.

[steven-legg]

The JSON part could make it in the (future) JSON Profile of XACML 4.0

Agreed.

[steven-legg]

The main additional thing of AttributesType is the category, therefore renaming AttributesType to CategorizedEntityType would make more sense I think.

It makes more sense to me too.