"Generated links" in savetext/usetext showing twice (and the second one is broken a bit)

[naglists]

Say what?

With Clay and Brandon's help, I am now successfully generating links from a
namespaced element, atidlm:resourcepair. However, if these links reside
inside of elements that get savetexted and usetexted, the link is output
twice.

For example in most contexts:
<atidlm:resourcepair ....=" tons=" of=" attributes=" live=" here=" ...="/>

Gets turned into:
<loc id="xxxx" role="table" type="link_with_title" title="titlegoeshere"/">

Which is subsequently formatted as a cross reference ... everything works
as designed. The link is live, highlighted properly, and contains all the
parts and pieces it should.

If, however, that <atidlm:resourcepair..../> lives inside of an element,
the content of which gets stored for later output, I end up with two links.
The first is "right" and the second one has the right text, is not entirely
live (only the ID/IDREF or numbering portion is live) or entirely
highlighted (same bits highlighted as live),

Any thoughts on what happens to links that are savetexted/usetexted?

--
Paul Nagai

[naglists]

No problem, Brandon,

Here are two related bits of the e-i-c's for
atidlm:resourcepair
loc

AND the markup of a link that would hit these two bits of FOSI coding. The
<dlmwrapper> can be ignored / omitted (assuming you clean up the specval's
and assume you're only processing links to "table". Long story why that is
there, but I'm fairly certain it doesn't play in what's going on.

Finally (below) I've dropped in the two elements' e-i-c's related to the
savetexting/usetexting of the content. They couldn't be simpler.

If the <para> containing the link is formatted simply, the link works.
If the <para> containing the link is savetexted and then usetexted, two
links are output. The first one works. The second one is sorta wonky.

I am hoping this is a FOSI oddity that can be worked out. I am afraid it is
internal to Dynamic Link Manager code somehow and can't really be accessed
directly. I've tried a bunch of tests and as far as I can tell, FOSI and
XPath treat the first and second instance of the <loc> as though they are
one and the same rather than siblings or parent/child or some other
"normal" relationship.


<att>
<specval attname="atidlm:markupType" attloc="atidlm:resourcepair"&lt;br"/>attval="link_with_title">
<specval attname="targetType" attloc="dlmwrapper" attval="table">
<charsubset charsubsetref="blue">
<usetext source="!&lt;loc type="link_with_title"&lt;br /&gt;role="table"&gt;!,#SETATTR(ID,@*[local-name()="targetXmlId"])#ENDSETATTR,#SETATTR(title,substring-after(@*[local-name()="targetName"],":&lt;br /&gt;"))#ENDSETATTR,!&lt;/loc&gt;!" placemnt="after"></usetext>
</charsubset>
</att>

<att>
<specval attname="type" attloc="loc" attval="link_with_title">
<specval attname="role" attloc="loc" attval="table">
<fillval attname="ID" attloc="loc" fillcat="savetext" fillchar="conrule">
<charsubset charsubsetref="blue">
<savetext textid="ididref.txt">
<usetext source="\Table\,ididref.txt,\," \,loc_title.txt&quot;<br="/>placemnt="after"></usetext>
</charsubset>
</att>

<para>
<dlmwrapper<br/>targetCleanName="1111222333 retitled target of link"
targetType="table">