Hi David, 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 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