Sometimes these details take a while to come into focus.
In this case, since you are looking to change "Attributes" to something
and have picked Category, for consistency w CategoryId, I would like
to point out what I consider a non-trivial issue w this choice.
(And since you are planning updates anyway, it will give another
chance to reconsider :) )
https://lists.oasis-open.org/archives/xacml/201307/msg00006.html
The issue is that the use of CategoryId in the current spec is a
semantic referring to how to interpret the collection of attributes.
i.e. it says what "type" of collection it is, but it does not say
anything about any specific instance of that collection type.
Therefore, naming the collection "Category" in the top element,
and then identifying the Category-Type using CategoryId is a bit
unusual because id-like attributes are generally used to identify
specific instances of the content as opposed to the type of
content.
One example that comes to mind is the SAML <Assertion> element,
that has an AssertionId attribute. This attribute is used to identify
the specific instance of the Assertion and is not saying anything
about the type of assertion. I know this example is dated and
the community is now using the xml id construct, but the point
is that id generally refers to the content, whether appl-specific
or xml general.
Using <Category CategoryId=xxx ...> I think is missing the point
that it is the content itself that needs to be interpreted using
the specific Category type identified in the top element.
This does not to me indicate that there is any semantic value
in calling the top level element, "Category", as category is only
one possible metadata aspect of the collection. Possibly, we
would one day add an "IssuerID" to the top level to identify
the entity that created the collection as opposed to the
individual attributes. Then we would have to choose whether
to call the top element either Category or Issuer, neither of
which makes particular sense to me.
In any event, as indicated yesterday, I don't want to hold up
the profile by trying to use it to correct a flaw in the core
spec, but I think the name of the top level element could
be anything and Category may or may not be the best
choice given that we are only not constraining it to the
"Attributes" choice, that unfortunately is in the core spec.
Therefore, I will defer to your judgement as to what to do,
but wanted to register my comment on the current state.
Thanks,
Rich
On 7/3/2013 3:53 AM, David Brossard
wrote:
The last time I was on the call 3 weeks ago, I said I was ok with using the word entity.
All things considered, I don't want to do that. While I think it's a great idea, I don't want to deviate the JSON profile from XACML 3.0. It will make training and explanations more complicated.
If I decide to call the <Attributes/> element something else, I should call it Category since the first child is CategoryId and the notion of a category is well established in XACML 3.0
If I call it Entity then I'd have to rename CategoryId to EntityId or plain Id. I would then have to explain to users of the JSON profile what Entity is and why a different name was used. That just complicates things.
So I'll stick to the name Category.
Any big massive objection? I have been slow and delayed in this work so I now want to finish it off. This is - I believe - the last detail. I've also written sample code which complies with the profile to verify the workability of the profile. It looks good so far.
Cheers,David.
--
David Brossard, M.Eng, SCEA, CSTP
Product Manager
Axiomatics AB
Skeppsbron 40
S-111 30 Stockholm, Sweden
http://www.linkedin.com/companies/536082
http://www.axiomatics.com
http://twitter.com/axiomatics
--
Thanks, Rich
Thanks, Rich
Rich Levinson | Internet Standards Security
Architect
Mobile: +1 978 5055017
Oracle Identity Management
45 Network Drive | Burlington, Massachusetts 01803
Oracle is committed to developing practices
and products that help protect the environment