Where are customized element lists stored ?

Report · Oct 05, 2011

Hi all,

After removing lots of useless DITA elements from my Elements list via the Customized List option, I find that the list is only used for the document in which I have edited it, and is not kept when I close and reopen the DITA file.

In the FM10 help file I read that the customized list applies to a document - or possibly to a set of documents in a book that were selected when opening the Customized List option. In DITA topics, there is no use for an FM book file, so this documented option is pretty useless for those types of structured files.

Does anyone know where the customized elements list is stored ? Can it be copied and pasted into other documents ? Is there an easy method to make it valid for all (new and existing) documents of the same DITA type ?

Thanks

Jang

Report · Oct 05, 2011

Jang,

I fear it is the same as with customized paragraph, character, and table formats: They are stored with the document. There seems to be no way to access them via FDK or by scripting. There is no option to import them from one document to another.

If you work with XML files, there might be a way to supply a customzed list of elements to authors vir the template file, as every XML document is opened in the structure application’s template, effectively creating a new document each time. But I have not tried this.

- Michael

Report · Oct 05, 2011

Thanks Michael, but I just wanted to find a way to help newbies to work with DITA without becoming geeks. I will have to tell them not to bother with the lists of useless elements, just pick out the ones they need. And of course hire me to do some customizing of their DTDs and EDDs...

Writing the file into DITA format obviously removes all FM-specific info from the file, as reopening the file shows the same full list of elements again. Oh well, there is something to be desired in new releases. I will check it on FM11 later today and see if I can shoot a feature request into the prerelease program.

Ciao

Jang

Report · Oct 05, 2011

Jang...

When you're working with XML files, the element list is defined by the structure application template you apply when opening the file. To strip out elements you'll need to create a clone of the structure application(s) you're using then modify the underlying EDD to carefully remove the elements from the general rules .. then import that back into the template. With FM10 there's one structure application per doctype (task, concept, reference, ...), although you can simplify this by using the "ditabase" model and a single structure application .. like in FM8 and FM9. You could just modify the default structure applications, but that's a really bad idea .. you should create new apps with new names so you can switch from your simplified model to the full model easily.

Cheers,

...scott

Report · Oct 05, 2011

Hi Scott,

I understand what you're saying. However, I do not want to change anything to the underlying DTDs, EDDs or read-write rules. I just want to hide a number of elements in FrameMaker without changing anything else. This effectively implements one aspect of constraints (the other aspects, namely making optional elements mandatory or defining an order where this is not given by the original DTDs, are not possible without using the method you indicate.

At first I was happy with the simple notion of editing the visibility of elements in the editor. This is a feature that several XML editors have also implemented. But in FM, any change to the elements catalog is lost as soon as the file is closed, and that makes this feature really useless. Noboby is going to go through the same stupid process of selecting all those wanted elements or deselecting the unwanted ones every time a file is opened again.

Michael pointed me in the right direction to solve this problem the easy way: after defining the custom elements catalog in a DITA file and removing all elements from it, I saved the file as an FM file, renamed it to topic.template.fm and placed it in the DITA templates folder (effectively overwriting the old file - but of course I renamed the old one first). Now, whenever I open a topic type file, the custom elements catalog is read from the template. This is done for all DITA files of the topic type, not just the newly created ones.

This is exactly what I would expect as FM's default behavior, so I am happy that it works. Takes some of the geek stuff out of DITA in FM.

Ciao

Jang

Report · Oct 05, 2011

Hi Jang...

Ah, yes .. I forgot about that feature! Right, you can edit the template file by customizing that list and set that as the default option. The problem is (for me), that list remains sorted as you define it .. it doesn't change to sort with the valid elements at the top of the list. This may be OK if you've trimmed the list *way* down so you can easily see everything without scrolling, but otherwise you may not see a valid element at the bottom of the list. It would be great if there was an option to specify the trimmed list but have it auto-sort as well.

I agree that this is definitely a better way to work for beginners (and not so beginners). However, if this is something that you're setting up for a client, it might be worth taking the time (not much needed) to provide the trimmed down EDD as well. You don't need to mess with the DTD, and you'll get the nicer element selection option as well.

Cheers,

...scott

Report · Oct 05, 2011

Hi Scott,

That is true, the elements appear in one and the same order when you use a customized list. I do not understand the reasoning behind that choice. After all, the only thing I want to achieve by setting a customized elements catalog is blending some elements out, not change the behavior of the list completely. So yes, if a client asked me to set up their environment with constraints, I would definitely go through the only correct process of creating an adapted DTD and EDD plus templates - the works. I have done this using the DITA Specialization option and it works fairly well. The reason to include the work on the DTD as well is that the constraints would be valid for all editing and publishing environments that use the same set of DITA files.

Ciao

Jang

Report · Oct 06, 2011

Hi Jang...

Just one more point .. when you're doing this subsetting of DITA elements, you only need to modify the EDD (and import that back into the template) .. you don't need to touch the DTD. It's OK for the DTD to allow the full set of DITA elements while the EDD is restrictive. This is nice since you can have the restrictive app and the full app using the same DTD files.

Cheers,

...scott