Assign an ID to an Element

[frameexpert]

When I right + click on an element, I can choose Assign ID to Element. Is there an ExtendScript function or method for doing this? Thanks.

Alternatively, is there a solid JavaScript algorithm for generating an unique value? -Rick

[Ian Proudfoot]

ExtendScript supports XPath through the E4X extension. So you could use the XPath generate-id().

I believe that the FrameMaker Assign ID to Element command was originally part of the DITA add-in, so maybe it's possible to access it that way?

[Ian Proudfoot]

But of course there isn't a direct correlation between the FrameMaker object model and the E4X model...

[frameexpert]

Hi Ian,

It looks like ExtendScript's xpath method returns an XML object, so I don't think I can use an xpath function to return a string value. Thanks for the reply.

Rick

[Ian Proudfoot]

Yes I had already negated my original suggestion. How about using the FrameMaker element's own object ID as the basis for an XML ID? A simple function could force the result to comply to XML name rules...

[frameexpert]

After I posted, I found some decent JavaScript code for generating ids, but I was hoping I could just use an existing ExtendScript method if it was available. I modified it to give me this:

function getUniqueId (element) {
    return ((Date.now ().toString (36) + Math.random ().toString (36)).toUpperCase () +
        element.Unique);
}

[Ian Proudfoot]

Rick,

There is some merit in always generating the same XML ID for a given node in a structured document. In this function it will be different each time for the same element...

Ian

[frameexpert]

Hi Ian, Right, but in this particular case, I am assigning the new value to the id attribute anyway, so it will be already set the next time I need it.

Here is the background: I have a custom EDD where the id attributes on <section> and <procedure> are optional. I am building a chapter TOC so I need to pick up the current id value (if it exists) or assign a new one if it is needed. Once it is set, then it will get picked up the next time the script generates the TOC. Thanks again for your feedback. -Rick

[Russ Ward]

Hi Ian,

With apologies to Rick if I am hijacking this thread, I am curious about what you said:

"There is some merit in always generating the same XML ID for a given node in a structured document"

I've never seen that use case. I'm curious to know when that would be applicable. It seems that you are referring to a case where an ID gets applied multiple times, which is different than any workflow I've used.

Also, I really like the idea of using FM's unique ID. If you wanted the IDs to look like the 8-character alphabetic IDs that FM generates, you would need a little extra code to convert, which wouldn't be difficult. But if you truncated to 8 characters, you would lose the assurance of uniqueness, I suppose. Every time I've needed an 8-character unique ID, I've just generated it, then checked it against all other IDs in the doc. A bit expensive for sure, but I've never noticed any problem as FM is very fast at such operations.

Russ

[Ian Proudfoot]

Hi Russ,

I can't imagine why you would want to have the id of a node change at any time.

My opinion is based on the XSLT and XPath models where the identity of a given node is inherently unique. In that case the generate-id() function will create the same id each time it is applied in the current transformation. For example I apply an id attribute to an element in one part of a transformation and then use the node's identity to generate part of the @href for a result-document. In another part of the stylesheet I generate the xinclude @href to that newly created file in a master file all safe in the knowledge that the ID will be constant and won't need to be checked. ( I still do check of course but as a final validation step and it has never failed).

It's easy and efficient. So moving to the FrameMaker environment I try to apply the same logic. OK my first answer to this thread was off the mark (I was heavily into a big XSLT project and was thinking in xpath) but I do use the FrameMaker element's own internal UID when I need to generate an XML ID. It's just the most efficient way.

Of course when you use FrameMaker to export to XML the Element's Object UID will be different once the FM doc has been reopened from the XML, but the same is true of XML and XSLT.

[frameexpert]

Thanks to all of you guys for participating. In the context of XSLT, what Ian is saying is absolutely true: in some transforms, it is critical to be able to use generate-id() to build reliable cross-references, or to compare nodes, etc. In this case, I just want to assign a unique value to an element's id attribute, if it didn't already have one. Once I generate the value, I assign it to the id attribute and that element is taken care of forever. Like Jang and Russ said, I can use the element's Unique property to generate an id. This will work for this particular task--making a chapter TOC.

However, it is possible to have duplicate Unique values within a book. Since FrameMaker has a function to assign an id to an element, I thought this might be exposed to ExtendScript. Why build a function if one is already built in? But I am satisfied with the little function I posted above. By combining the current time, a random number, and the element's Unique property, I am pretty sure these will be as "unique" as I need them to be. Thanks again to all you guys, who I greatly esteem.

[Russ Ward]

If you absolutely, positively want to be sure that the ID is unique in practically all the world -and- you don't care how long it is, you could always include a timestamp with it

Ian, thanks for the explanation. Totally makes sense now in the context of XSLT.

Russ

[4everJang]

No need for all kinds of code, Rick. Every object in FrameMaker has a unique ID. When you have the element object, you can read that unique ID from its Unique property. Note, however, that these are numbers. To make these valid IDs in XML you need to prepend them with a character, as IDs cannot start with a digit.

I have been using this for as long as ExtendScript exists and never found a duplicate ID.

[Ian Proudfoot]

Agreed Jang, which is what my answer (post 4) stated.

- Ian

[4everJang]

I overlooked that in the thread, just saw the XPath mentions and thought that is absolute overkill. 🙂