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
