Re: [xacml] Is the choice element in Policy correct

Hi Erik,

    

    At this point we are simply trying to determine what the schema
    should be,

    in the sense that if it was reflecting the intended behavior, what
    changes

    would be appropriate.

    

    For example it would seem the appropriate changes might be:

    
      
A Policy must have one or more Rules.

      
A Policy may have zero or more VariableDefinitions

      
A Policy may have zero or one CombinerParameters

      
A Policy may have zero or one RuleCombinerParameters

    
    If these are the actual requirements that are intended, or if some

    other specific requirements are more accurate or appropriate, then

    the purpose of the issue being raised is to determine what are the

    correct requirements.

    

    Once the requirements are established, then we can evaluate what,

    if any, impact that might have on the schema, and whether the

    TC thinks the schema should be changed.

    

    At present, it appears that the current schema does not reflect

    any kind of plausible real requirements, and this represents

    a problem for developers using the specification to build products,

    because they may be uncertain how to handle the use cases that

    are made possible w the current schema.

    

        Thanks,

        Rich

    

    

    On 1/27/2012 6:10 PM, Erik Rissanen wrote:
    
      
      Hi Rich,

      

      I don't think there is anything which needs to be changed here.
      It's true that the schema is a bit weird in this respect. It's a
      carry over from 2.0, and does not represent any practical concern.

      

      Empty policies are fine I think, though it does not really make
      sense to have an empty policy with variables since there would be
      no rule to use them.

      

      But there is not really any issue in how to interpret any
      combination which the schema allows and there is no reason for a
      product to produce meaningless policies.

      

      I would say that we keep it as it is.

      

      Best regards,

      Erik

      

      

      On 2012-01-24 07:23, rich levinson wrote:
      
        
        To TC:

        

        We have been looking at the xsd for Policy and there is a
        central

        "choice" element that does not appear correct, although for

        mainstream Policies it probably does not show up.

        

        The choice element is the following:

         2028

          <xs:choice maxOccurs="unbounded">

              <xs:element ref="xacml:CombinerParameters"
          minOccurs="0"/>

              <xs:element ref="xacml:RuleCombinerParameters"
          minOccurs="0"/>

              <xs:element ref="xacml:VariableDefinition"/>

              <xs:element ref="xacml:Rule"/>

          </xs:choice>

        
        This is the construct that allows multiple Rules in a Policy,
        which, looking at

        the Rule element alone, seems ok, as default is minOccurs="1",
        and it

        inherits maxOccurs="unbounded" from the choice element itself.

        

        However, very little else about this element appears to make
        sense:

        
          
Since this is a choice element, w minOccurs="1", one could
            choose any

            of the other 3 elements and nothing else, and the result
            would be a

            Policy with zero Rules. Does this make sense?

          
With zero Rules, even if you used the Policy to define
            VariableDefinitions,

            they cannot be referenced outside the Policy, and since
            there are no

            Rules in the Policy, there is nothing that would ever use
            the

            VariableDefinitions.

          
Does it make sense to have multiple instances of either
            CombinerParameters

            or RuleCombinerParameters? i.e. can't all the parameters be
            put in one

            element in both cases? If not then why are these elements in
            the choice

            block that allows unbounded instances?

        
        Please advise as to whether the above interpretation is
        accurate. If so, we would

        like to consider raising this as an issue for action.

        

            Thanks,

            Rich