Any real difference between do-strip-op-attr name="X" and do-strip-xpath expression='./modify-attr[@attr-name="X"]' ?

I'm tweaking an O365 driver and noticed that in the
"sub-ctp-HandleAttributes" the netiq packages use:

do-strip-xpath expression='./modify-attr[@attr-name="CN"]'

I know if the event was an add or instance, do-strip-op-attr would
still kick in. However in this case the rule is already scoped to only
apply to modifies.

So is there any reason why they didn't use do-strip-op-attr here
instead?

Both will remove the remove-all-values child element, which they
selectively add back in.
  • Alex McHugh wrote:

    > So is there any reason why they didn't use do-strip-op-attr here
    > instead?


    I would expect both ways to do exactly the same, probably just a matter of
    personal preference or even pure coincidence of which token came to mind first.

    Your question reminds me that I wanted to write down all xpath equivalents to
    tokens and conditions for years. I really should get around to doing it to
    clarify what exactly the tokens do and don't. For example I recently used "if
    operation attribute available" on an incoming add from the generic file driver,
    which creates empty <value> nodes for empty CSV fields.

    How do you expect "if operation attribute available" to evaluate when testing
    against something like:

    <add class-name="...">
    <add-attr attr-name="...">
    <value/>
    </add-attr>
    <add>

    --
    http://www.is4it.de/en/solution/identity-access-management/
  • Lothar Haeger <lothar.haeger@is4it.de> wrote:
    > Alex McHugh wrote:
    >
    >> So is there any reason why they didn't use do-strip-op-attr here
    >> instead?

    >
    > I would expect both ways to do exactly the same, probably just a matter of
    > personal preference or even pure coincidence of which token came to mind first.


    I just prefer to use regular tokens before resorting to XPath.

    In the rare event that engineering makes underlying changes (like with the
    new lite associations). The onus is on them to update the association
    tokens so they support the new format.

    > Your question reminds me that I wanted to write down all xpath equivalents to
    > tokens and conditions for years. I really should get around to doing it to
    > clarify what exactly the tokens do and don't.


    That is a great idea.

    > For example I recently used "if
    > operation attribute available" on an incoming add from the generic file driver,
    > which creates empty <value> nodes for empty CSV fields.
    >
    > How do you expect "if operation attribute available" to evaluate when testing
    > against something like:
    >
    > <add class-name="...">
    > <add-attr attr-name="...">
    > <value/>
    > </add-attr>
    > <add>
    >


    I expect it to be true.


    --
    If you find this post helpful and are logged into the web interface, show
    your appreciation and click on the star below...
  • On 3/31/2016 9:34 AM, Lothar Haeger wrote:
    > Alex McHugh wrote:
    >
    >> So is there any reason why they didn't use do-strip-op-attr here
    >> instead?

    >
    > I would expect both ways to do exactly the same, probably just a matter of
    > personal preference or even pure coincidence of which token came to mind first.
    >
    > Your question reminds me that I wanted to write down all xpath equivalents to
    > tokens and conditions for years. I really should get around to doing it to
    > clarify what exactly the tokens do and don't. For example I recently used "if
    > operation attribute available" on an incoming add from the generic file driver,
    > which creates empty <value> nodes for empty CSV fields.
    >
    > How do you expect "if operation attribute available" to evaluate when testing
    > against something like:
    >
    > <add class-name="...">
    > <add-attr attr-name="...">
    > <value/>
    > </add-attr>
    > <add>


    That is available. It does not mean has a value greater than 0, rather
    there is a value node.

    As for XPATH equivalents, I tried doing that in my book to explain how
    things work, but also to teach XPATH backwards.


  • Alex Mchugh wrote:

    > > How do you expect "if operation attribute available" to evaluate when
    > > testing against something like:
    > >
    > > <add class-name="...">
    > > <add-attr attr-name="...">
    > > <value/>
    > > </add-attr>
    > > <add>
    > >

    >
    > I expect it to be true.


    Yes, that's what IDM does. But from a business logic perspective (as opposed to
    a programmer's look at XDS) <value/> means there is no (Surname, Email, Date of
    Birth - enter our data item of choice) available, because the business logic
    does not care if it's an empty node, a node with an empty string text node or
    no <value> node at all.
    Once you're deep enough into IDM to see that difference, it's clear (though
    still not intuitive, at least to me). An if one actually wants to know if you
    have a value to work with or not ("value" as in data item, not as in <value>
    node) one needs to use "if operation attribute equals regex . " (unless you
    have a structured attribute, of course, when it gets even less straight
    forward...).

    If I had run into this ten years ago I'd be pretty upset about that stupid
    token doing it obviously wrong and probably complained in a thread here. In my
    opinion, tokens should be equivalents of business-relevant logic. If one needs
    to be pedantic on an abstract XML level, XPath is the tool of choice.

    What's your take on the XPath equivalent of "if operation attribute available",
    btw.? Would

    <add class-name="...">
    <add-attr attr-name="..."/>
    </add>

    also evaluate to true (and would you have designed it that way if you were the
    IDM developer in charge)?

    --
    http://www.is4it.de/en/solution/identity-access-management/
  • Geoffrey Carman wrote:

    > That is available. It does not mean has a value greater than 0, rather there
    > is a value node.


    Really? So it tests for a <value> node? Or for a <add-attr> with a matching
    @attr-name, maybe? Or just a matching .//@attr-name anywhere in the operation
    (excluding everything below ./operation-data or not?

    > As for XPATH equivalents, I tried doing that in my book to explain how things
    > work, but also to teach XPATH backwards.


    So what did you come up with as XPath equivalent in this case?


    --
    http://www.is4it.de/en/solution/identity-access-management/
  • On 3/31/2016 1:13 PM, Lothar Haeger wrote:
    > Geoffrey Carman wrote:
    >
    >> That is available. It does not mean has a value greater than 0, rather there
    >> is a value node.

    >
    > Really? So it tests for a <value> node? Or for a <add-attr> with a matching
    > @attr-name, maybe? Or just a matching .//@attr-name anywhere in the operation
    > (excluding everything below ./operation-data or not?


    A fair question. Available, I THINK is looking for the <value> node,
    regardless of if it has contents.

    I say this, because Changing looks for add-value, remove-value,
    remove-all-values nodes. I am NOT sure if they need a <value> node
    underneath to detect, but I imagine not in that case.

    >> As for XPATH equivalents, I tried doing that in my book to explain how things
    >> work, but also to teach XPATH backwards.

    >
    > So what did you come up with as XPath equivalent in this case?


    Buy a copy, cheapskate. :) Actually, did you get a copy at Brainshare? :)

    In this case, I did not. I guess, without much thinking I would have
    done something like:

    XPATH:
    modify-attr[@attr-name=$ATTR]/add-value|add-attr[@attr-name=$ATTR]/value



  • Lothar Haeger <lothar.haeger@is4it.de> wrote:
    >
    >
    > Yes, that's what IDM does. But from a business logic perspective (as opposed to
    > a programmer's look at XDS) <value/> means there is no (Surname, Email, Date of
    > Birth - enter our data item of choice) available, because the business logic
    > does not care if it's an empty node, a node with an empty string text node or
    > no <value> node at all.
    > Once you're deep enough into IDM to see that difference, it's clear (though
    > still not intuitive, at least to me). An if one actually wants to know if you
    > have a value to work with or not ("value" as in data item, not as in <value>
    > node) one needs to use "if operation attribute equals regex . " (unless you
    > have a structured attribute, of course, when it gets even less straight
    > forward...).
    >
    > If I had run into this ten years ago I'd be pretty upset about that stupid
    > token doing it obviously wrong and probably complained in a thread here.


    Like I guess most who have worked with IDM it didn't take me long to run
    into this type of issue and discover the same workaround you mention.

    Many others have used the workaround of

    if operation attribute not equals ""

    Which I really dislike.

    > In my
    > opinion, tokens should be equivalents of business-relevant logic. If one needs
    > to be pedantic on an abstract XML level, XPath is the tool of choice.


    Agreed.

    > What's your take on the XPath equivalent of "if operation attribute available",
    > btw.? Would
    >
    > <add class-name="...">
    > <add-attr attr-name="..."/>
    > </add>
    >
    >
    > also evaluate to true (and would you have designed it that way if you were the
    > IDM developer in charge)?
    >


    no and no.

    --
    If you find this post helpful and are logged into the web interface, show
    your appreciation and click on the star below...
  • Geoffrey Carman wrote:

    > Buy a copy, cheapskate. :) Actually, did you get a copy at Brainshare? :)


    To be honest, I was holding my breath every time we ran into each other, but
    you never pulled a signed a copy to give it to me. You were probably afraid I
    might rejected it, I guess (I wouldn't!). ;-)

    > In this case, I did not. I guess, without much thinking I would have done
    > something like:
    >
    > XPATH:
    > modify-attr[@attr-name=$ATTR]/add-value|add-attr[@attr-name=$ATTR]/value


    How about instance docs? And queries: does a search-attr match or a read-attr
    or both or none?


    --
    http://www.is4it.de/en/solution/identity-access-management/
  • On 3/31/2016 2:01 PM, Lothar Haeger wrote:
    > Geoffrey Carman wrote:
    >
    >> Buy a copy, cheapskate. :) Actually, did you get a copy at Brainshare? :)

    >
    > To be honest, I was holding my breath every time we ran into each other, but
    > you never pulled a signed a copy to give it to me. You were probably afraid I
    > might rejected it, I guess (I wouldn't!). ;-)


    So you did not come by for a signed copy? Sorry, I was not carrying ANY
    with me. They are heavy! Signed 100 of them... Too lazy to wait in
    line eh? You should have parachuted from the upper deck down to cut the
    line.

    >> In this case, I did not. I guess, without much thinking I would have done
    >> something like:
    >>
    >> XPATH:
    >> modify-attr[@attr-name=$ATTR]/add-value|add-attr[@attr-name=$ATTR]/value

    >
    > How about instance docs? And queries: does a search-attr match or a read-attr
    > or both or none?


    Good point. Missed that. Which is why I use the tokens, not raw XPATH.
    :) Same issue with reformat op attr. Handles many cases you might not
    immediatly think of.

  • So you did not come by for a signed copy? Sorry, I was not carrying ANY with me. They are heavy! Signed 100 of them...

    It is looks like you have to start exercises to be prepared to sign hundreds copy of your new "IDM Validator: The Missing Manual" book during TTP 2016. :)