Missing "rowheader" attribute in table

[dmurphy]

We have just upgraded from XMetaL version 9 to version 12. We are now getting the following error when topics are checked out that contain tables:

“Bad or missing attribute. A value for required attribute “rowheader” must be specified”

Double-clicking the error in the Results window takes me to the tgroup. But the rowheader attribute is not available on that element. I've tried specifying “norowheader” in the attribute for the table element, but that makes no difference. XMetaL says the document is invalid, and will not save it. Any ideas?

Reply

[Derek Read]

If this is one of the standard DITA DTDs there is a rowheader attribute on the

and elements.

However, this attribute is not required in any version of the DITA DTDs that I'm familiar with. Perhaps you are using a specialized DITA DTD?

XMetaL uses the actual DTD for any document you are authoring to perform validation, so it is almost guaranteed that this attribute is actually required in your case. Knowing exactly which DTD you are working with would let me tell you for sure (or send a sample to XMetaL Support and they can help you work it out).

When you are in Tags On or Normal view XMetaL Author tries to take you to the closest location that it can when you click on an error in the Validation Log, but it might not be able to take you exactly there for some reason (ie: if you cannot normally visit that element in a particular view).

If you validate the document (F9) while viewing it in Plain Text view clicking on an error in the Validation Log should take you to the precise location of the error in the document, or much closer to it (if for example an element is missing it obviously can't take you to the missing element but to the element that requires it).

The Attribute Inspector also shows required attributes for any given element in bold face when you put your selection inside that element.

The Table Properties dialog allows you to modify most standard portions of a table, including all the various attributes accessible for a CALS table, but this does not include @rowheader. There is also no way to place an insertion point inside a element in Tags On or Normal view (as making related changes is normally done through the Table Properties dialog). So, if your DTD does force this attribute to be required, and it is on a element you may need to switch to Plain Text view to access. If this is really what's going on the software could be customized to try to accommodate this need through scripting (APIs) or possibly also through an additional custom dialog.

Reply

[dmurphy]

Thanks for the reply, Derek. If I double-the error while in Plain Text view, it takes me to the colspec element. If I insert rowheader=”norowheader” into each of the colspec elements, I do not get the errors anymore. But when I try to save or check it in, it throws an “invalid against DTD error.”

We do not use a specialized DTD. However, I noticed that in the topic that has the errors, the DOCTYPE line is this:

But in a newly created topic, it is this:

If I create a new topic, copy all content from the topic that has the errors, and paste it into the new topic, it does not report the “rowheader” errors. But if I change the DTD reference in the topic with the errors, to the one from the new topic, it still has the errors.

So I believe you're right, it's a DTD issue, but I just can't figure out how to resolve it. I don't want to just create topics and copy all content into those because we would lose all of the versioning info for the topics (we use a CMS).

Reply

[dmurphy]

Derek – I have a solution for this. We cannot use DITA 1.3 yet because the custom output we use does not support DITA 1.3. I didn't know about the default setting for DITA version in XMetaL. After switching from DITA 1.3 to 1.2 in Tools > DITA Options, no more errors about rowheaders in tables!

Thanks.

Reply

[Derek Read]

I guess the error “invalid against DTD error” must be coming from some 3rd party (outside of XMetaL Author) system?

Can I assume you have XMetaL Author integrated with something else like a CMS?

If so, then I guess you should check with the people running it to be sure you are meeting any input requirements. It sounds you have done that (ie: must use DITA 1.2) but just in case there are others I'd suggest you confirm.

Still not sure why XMetaL Author would be giving a validation error about rowheader. As far as I can tell it has never been a required attribute (from DITA 1.x through 1.3). That suggests there is some other DTD involved here that has it set to #REQUIRED.

Reply

[Derek Read]

In case this is actually a concern for some reason, the DITA 1.2 spec lists it as an #IMPLIED attribute (and the DTD that I have shows it that way as well).

https://docs.oasis-open.org/dita/v1.2/os/spec/langref/table.html

That suggests to me that the DTD being picked up for you (DITA-1.2/technicalContent/dtd/ditabase.dtd), which will be relative to the XML file at that location (ie: in a subfolder called DITA-1.2), defines this attribute as #REQUIRED.

But, if you are using the following DOCTYPE then (by default at least) you should be getting the DTDs that are installed with XMetaL Author provided there is no DTD named “reference.dtd in the same folder as the XML file (which I would expect is the case):

However, if a CMS is involved then it could be that nothing I've said above applies as CMS integrations often change where DTDs are loaded from by customizing XMetaL Author's behaviour through configuration and scripting.

Reply

[dmurphy]

Hi Derek – Sorry, I should have mentioned that in the beginning. We are using an SDL CMS. We use SuiteHelp 4 output type, which does not support DITA 1.3. I guess SuiteHelp 5 does support it.

Reply

[[email protected]]

Fyi, I ran into this issue with XMetaL 12 as well.

Looks like there was an error in this file, which I assume was installed by XMetaL:
“C:\Program Files\XMetaL 12.0\Author\DITA\DITA_1.3_DTD\base\dtd\tblDecl.mod”

There was an erroneous line on line 157, where IMPLIED/REQUIRED should have been. I replaced this line with #IMPLIED and the issue went away.

Just thought I’d post this in case anyone else comes across the issue!

Reply

[Author]

Posts