Is it possible to have values($String) only process on a specific container?

Is it possible to have values(“AttributeName”) or values(children,“Attribute”) be used in connection with a note other than the note of focus, e.g., $Text=values($Name(“Project Atlas”) ); or $Text=values($Name(/Projects/Project Atlas) );

I have a file with many hundreds of notes. I want to spellcheck the names in a specific container, not the whole file.

See values(), specifically the optional first input scoping parameter.

Thanks, Mark. I understand the syntax of the values, but I was hoping to be able to apply it along side a separate note. It took me a few times reading through values() action and I finally find my answer over on collect().

Let me explain my logic failure and hopefully others can learn.

I’ve gotten used to doing this with export code: ^value($Attribute("ANOTHER NOTE NAME"))^ to pull in values form a different note. So I was trying to replicate, what I’ll call syntax, of applying the parenthetical argument to $Attribute to pull values from the other note.

What I’ve just learned, thanks to the holy book of aTbRef, praise be to Mark, is that the parenthetical syntax in the action code should not be place on the attribute name but rather the group designator, e.g.

$Text=values(descendants("ANOTHER NOTE NAME"),"Name").replace(";","\n");
or
$Text=collect(descendants("Gateway Offboarding Flows"),$Name).unique.replace(";","\n");

Both the above achieve the same objective.

VERY cool, thanks!!!

Thanks. values("SomeAttr") is whole-doc scope by default, i.e. all discrete values of attribute ‘SomeAttr’ across the entire TBX. But if one wanted the same but for part of the TBX a scoped collect() or collect_if() was the way to go.

To address the latter values was extended to allow an additional optional scoping argument to restrict the range of notes it checked. Note that, unusually, the optional second parameter is supplied as the first parameter as is explained in my notes on values().

Although less pertinent in the example at the end of the previous post, be aware that collect() and collect_if() return a List rather than a Set so it may contain duplicates. In such a situation, chin in .unique. As the list is not necessarily sorted, it can help to chin .sort as well. So, adapting the earlier example to use $Tags - where dupes might well occur:

$Text=collect(descendants("Gateway Offboarding Flows"),$Tags).unique.sort.replace(";","\n");

By comparison, neither extra operator is needed here:

$Text=values(descendants("ANOTHER NOTE NAME"),"Tags").replace(";","\n");

as values() returns a Set so is automatically de-duped and the values are lexically sorted as would be done by .sort.

So the two-parameter values() syntax is simpler for a scoped value listing as it does some of the likely desired mis-en-place for you. Thus for new code, I’d go with that over collect(). But, I’d not rush to change existing use of the latter; if it already work, it’s fine as it is.

1 Like