Personally, I think that version stuff belongs in a PDP metadata reference. The reasoning being that it is horribly inefficient to version every value, particularly when such things are generally managed as part of a larger specification. This also has the benefit of making interoperability easier when viewed as part of the larger context (profiles supported, custom extensions, etc.)
b
> On Apr 28, 2017, at 4:56 AM, BFC.McLean <> wrote:
>
> Tiny point re: CVs : Might want to make them 3-part! Code base, version, key. Of course the first two could be concatenated but the two are really separate variables.
>
> Martin
>
> Sent from my iPad
>
>>> On Apr 28, 2017, at 2:25 AM, Steven Legg <> wrote:
>>>
>>> On 28/04/2017 6:56 AM, rich levinson wrote:
>>> Documentation of HL7 data types: ref from David wrt "compound attributes":
>>> https://lists.oasis-open.org/archives/xacml/201704/msg00003.html
>>> compound attrs: variation of xml
>>> martin: datatype was sort of a code list: needed or covered?
>>> look up official country code:
>>> need datatype for "enumerated lists"
>>> rich: maybe have a key:value pair as a datatype?
>>
>> Isn't a key:value pair an XACML attribute? :-)
>>
>> I would have described the HL7 data types as multi-part identifiers, but as the
>> IHE-XACML binding is only interested in at most two parts, and one mandatory part
>> is an OID, it would have been a viable approach to treat each OID as an XACML
>> attribute id and the other part as the XACML attribute value, thus avoiding the
>> need for new data-types and functions.
>>
>> That aside, the entities profile provides two ways to represent
>> multi-part identifiers (or key:value pairs).
>>
>> A value of the CV data-type would appear something like this according to HL7:
>>
>> <xacml:AttributeValue dataType="urn:hl7-org:v3#CV">
>> <CodedValue code="1" codeSystem="1.0.14265.1"/>
>> </xacml:AttributeValue>
>>
>> Using the entities profile it could still be represented as XML without defining
>> a new data-type:
>>
>> <xacml:AttributeValue DataType="urn:oasis:names:tc:xacml:3.0:data-type:entity">
>> <xacml:Content>
>> <CodedValue code="1" codeSystem="1.0.14265.1" />
>> </xacml:Content>
>> </xacml:AttributeValue>
>>
>> The parts of the value would have to be extracted using XPath and the
>> attribute-selector function.
>>
>> Alternatively, using the entities profile, the parts could be represented as
>> nested attributes:
>>
>> <xacml:AttributeValue DataType="urn:oasis:names:tc:xacml:3.0:data-type:entity">
>> <xacml:Attribute IncludeInResult="false" AttributeId="urn:example:hl7:attribute:code">
>> <xacml:AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string"
>>> 1</xacml:AttributeValue>
>> </xacml:Attribute>
>> <xacml:Attribute IncludeInResult="false" AttributeId="urn:example:hl7:attribute:codeSystem">
>> <xacml:AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string"
>>> 1.0.14265.1</xacml:AttributeValue>
>> </xacml:Attribute>
>> </xacml:AttributeValue>
>>
>> The parts of the value would be extracted using the attribute-designator function.
>>
>> The tricky part is writing XACML expressions that have the same effect as the
>> new HL7 functions. The CV-equal and II-equal functions are straightforward, if a
>> little verbose. The II-to-string and II-match functions are doable, but contorted.
>> It would be much easier if there were an XACML function that behaved like the
>> Java/C ternary operator "?:", i.e., if the first argument is true then return the
>> second argument, otherwise return the third argument. The remaining functions
>> involve transformations that could perhaps be done in the PEP and PIP rather than
>> the PDP.
>>
>> It would be handy for policy writers using compound attributes if XACML supported
>> user-defined functions (think of a variable definition with parameters). To better
>> support use cases with compound attributes I would add user-defined functions and
>> a ternary operator. Representing compound attributes and processing them are
>> already covered by the entities profile.
>>
>> Regards,
>> Steven
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at:
>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail. Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
