Hi Paul,
This issue is to determine what is correct. Once that is determined
we
can discuss possible implications and what, if anything, should be
done about the problem, assuming a problem exists.
I think we need to focus on what the schema should contain, not
whether changing the schema would break existing implementations.
Otherwise, there won't be anything we can discuss if it involves
potential changes.
Thanks,
Rich
On 1/30/2012 9:06 AM, Tyson, Paul H wrote:
We have attestations of use for the current
schema, and any change would break those implementations.
Policy evaluation is specified by section 7 of
the spec, and I believe it is robust enough to handle
nonsensical instances allowed by this schema oddity.
Unless the current schema allows a policy
instance that cannot be evaluated successfully and
unambiguously by the procedures in section 7, I suggest we
leave it alone.
Regards,
--Paul
From:
[mailto:]
On Behalf Of rich levinson
Sent: Sunday, 29 January, 2012 21:15
To: Erik Rissanen
Cc:
Subject: 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
