External entity LI___1

[LeoraBetesh]

Our clients are working with XMetaL 5.1 using a CMS repository.

We have had a few files with strange behavior and when we opened them in plain code view we saw they contained the characters LI___1.  We don't know where these extra characters are coming from nor whether they were inserted by XMetaL or by the CMS.

In one case, we had a table which output an unwanted duplicate row.  When viewing the topic in the XMetaL structure view we saw the LI___1 in the place of the duplication.

Our CMS contact told us to go to Tools->External Entities and delete the entity but when doing so we got an error message “entity LI___1 could not be deleted because the document contains references to it.”

Our CMS contact also suggested that this character may have been added during a faulty cut and paste of rows.

Does anyone have more information about this entity reference?  How did it get into the file, how to we remove it and is this an XMetaL issue or CMS issue?

In case it is relevant the content is in DITA.

Thanks in advance,
Leora

Reply

[Derek Read]

The DITA DTDs only define one entity, the named character entity “nbsp” which is mapped to the non-breaking space character U+00A0.

There should typically be no need to use entities (text or otherwise) in DITA and I would avoid them and instead use the “content referencing” mechanism provided by DITA's conref attribute.

XMetaL Author Enterprise should not insert entities into a document unless specifically instructed to do so (though that can be done via script in addition to manual editing, so in theory a customized version of XMetaL could do this without you knowing).

In order for an entity to be referenced in a DITA document (because there are no entities except nbsp defined in the DITA DTDs) the entity would need to have been defined in the internal subset of the XML file in question, which would then appear something like this:

 
]>

...etc...

It would be best to check with the CMS vendor, the company that created the integration between the CMS and XMetaL, or any other tool vendors (if you use other tools to work with your files, including any automated processes).

It is extremely likely this entity is being added by another process external to XMetaL. You should be able to confirm this by checking a “clean” file (one with no entity declarations or references in it) into and out of the CMS using whatever means the CMS provides for this, external to the interface provided through XMetaL. If the file isn't “dirtied” by this method then you can suspect another tool or the connection between the CMS and XMetaL Author Enterprise (we refer to this connecting code as an “adapter”).

After you have eliminated all other possibilities and you suspect the adapter as being the cause you should check with the person or company that created the adapter. The adapter is essentially a set of scripts added to XMetaL that extends (and in some cases alters) the default behavior of XMetaL allowing it to interact with a CMS (adding check-in, check-out, and other actions the CMS supports). Such a script can be told to do virtually anything, including making modifications to documents open in XMetaL.

Reply

[richard.simms]

One of our problems is not being able to delete the entity reference, and therefore the entity itself, from the document in XMetal. Usually, the entity shows up in the edit window as a square box with its name and you can select and delete the entity there but in the case the entity is a row in a table and the entities do not appear in the edit window. They do appear in structure view but they cannot be deleted using the structure view.

Question: can we implement some kind of easy fix that either displays the entity for the table row in edit view so it can be deleted or update the dialog to delete entities to prompt to delete all references as well as the entity itself?

Reply

[Derek Read]

I think it might be best to submit a support case for this including any files that demonstrate the issue so we can examine what is in your XML and try to figure out how it is getting there (it sounds like you don't know who is putting these entities there). If you can provide information on how to work with your files stored on your local file system (ie: C drive) to reproduce the problem (rather than opening them from a particular CMS version which we may not have access to) that would be best.

If the entity itself is an entire table row it will not render in TagsOn or Normal view as our table rendering code does not support this. We are looking at adding such a feature in the future. However, this sounds different from the originally posted issue that talks about “LI___1” (unless that is the name of the entity containing the content for the table row).

If you are working with DITA, even though using entities is perfectly valid (part of the XML Recommendation) and there is nothing forbidding their use in the DITA specification, their usage is not recommended and the best practice for DITA is to use DITA's conref attribute for reuse (aka: content transclusion) instead. Unfortunately, XMetaL Author Enterprise currently does not support rendering of table rows that are conref'ed either (in TagsOn or Normal view). Support for this is  being worked on for a future release. You may wish to read this other post as it contains a suggestion for trying the INI setting tags_on_graphical_tables = false that works with current releases (up to and including 5.5) that might be acceptable (though for most people it will be an ugly hack): http://forums.xmetal.com/index.php?topic=155.msg480#msg480

Reply

[ghkrause]

Does anyone know how to write a script/macro to delete all occurancies of entities?
The golden solution would include a dialog where you can select entities to be kept or to be deleted.

Reply

[Derek Read]

This would be possible, but at this point we suspect that the CMS is introducing them, so it would be best to figure out why (and stop it). We're hoping the CMS vendor can help here (and the client is on contact with them now).

Reply

[Author]

Posts