Pages: « 1 2 3 4 5 6 7 8 9 10 »
 on: May 21, 2019, 06:34:42 PM 
Started by dmurphy - Last post by 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).

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): <!DOCTYPE reference PUBLIC "-//OASIS//DTD DITA Reference//EN" "reference.dtd">

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.

 on: May 21, 2019, 06:15:32 PM 
Started by dmurphy - Last post by 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.

 on: May 21, 2019, 04:27:48 PM 
Started by dmurphy - Last post by 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!


 on: May 21, 2019, 02:19:36 PM 
Started by dmurphy - Last post by 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:

<!DOCTYPE reference PUBLIC "-//OASIS//DTD DITA 1.2 Composite//EN" "DITA-1.2/technicalContent/dtd/ditabase.dtd">

But in a newly created topic, it is this:

<!DOCTYPE reference PUBLIC "-//OASIS//DTD DITA Reference//EN" "reference.dtd">

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).

 on: May 21, 2019, 01:19:45 PM 
Started by dmurphy - Last post by Derek Read
If this is one of the standard DITA DTDs there is a rowheader attribute on the <table> and <colspec> 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 <colspec> 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 <colspec> 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.

 on: May 21, 2019, 07:55:56 AM 
Started by dmurphy - Last post by 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?

 on: May 07, 2019, 01:53:40 PM 
Started by rakesh - Last post by Derek Read
I don't see any obvious issues with your catalog file that would trigger a crash. My guess is that something else being loaded is triggering the issue.

I do see that the XML file references a DTD on an HTTP server:
<!DOCTYPE urteil PUBLIC "-//MBO//DTD urteil 1.0//DE" "">

XMetaL Author will attempt to download the DTD, RLX or XAC file from that location together with any other files that XMetaL Author is able to obtain (CSS, CTM, MCR, possibly others). If XMetaL Author does find the DTD (or RLX or XAC file) it isn't going to use any entries from the catalog file. If it doesn't locate the DTD (or RLX or XAC) then it will use the entry in your catalog file to load the urteil.dtd from the same location as the catalog file, which will typically be in the Rules subfolder of the XMetaL Author installation.

Check to see that the DTD or other files do not exist at the HTTP server above if you don't want XMetaL Author to use that copy.

If you want thorough testing to be done on this, the files needed to reproduce the issue will be needed. That would include an XML sample (which you have provided here) but also the DTD, CSS, CTM, MCR, and any other files that the software is loading. Your issue could be due to the loading of the XML file itself, the DTD, any files that DTD references (entities, etc), the CSS properties interacting with the document, CTM settings or scripts, a script in the MCR file or a DLL that the MCR file references, maybe an XFT form, or perhaps some third party software the MCR or DLL code calls, possibly something else.

Please submit a support case to XMetaL Support here:

Note: That form does not accept file attachments. Once a case has been opened you can either send attachments via email. If email will not work for the files you need to send then XMetaL Support will let you know how to share them.

If 3rd party software is required to reproduce the issue (such as a CMS integration or some other software that modifies the XMetaL Author Enterprise installation to extend its functionality) please also let XMetaL Support know those details.

Please keep in mind that testing on version 6 cannot be done as it is an unsupported release. Testing will need to be done on a recent version. Issues are generally only corrected in the current release (right now that's 14) though exceptions are made for clients that must use a slightly older version that one of our partners requires in order to function with their software.

From the install-readme for XMetaL Author Enterprise 6 SP1 (released Jan 2010):

• Microsoft Windows XP, Vista, 7* or 2008 Server
* Windows 7 support is pending as only preliminary testing has been completed to date. Although no problems have appeared with XMetaL Author Enterprise under Windows 7, please use XMetaL Author Enterprise at your own risk.

 on: May 07, 2019, 01:56:55 AM 
Started by rakesh - Last post by rakesh
Hi Derek,

Yes XMetal 6.0 is working fine on Windows 10. I have attached a screen of "About XMetal Author Enterprise deilog" for your review.

My only concern is when I am opening a xml file (attached) that have a public URI say "<!DOCTYPE urteil PUBLIC "-//MBO//DTD urteil 1.0//DE" "">', the XMetal  stops working and crashed. I am using Windows 7.

I have used catalog file (attached) to ignore doctype from xml but it is not working.

I am using the same setup of XMetal on Windows 10 with the catalog file and it is working fine. XMetal ignore the doctype.

I want to open the attached xml file into my XMetal 6.0.


 on: May 06, 2019, 07:04:45 PM 
Started by queshaw - Last post by Derek Read
If you set the ButtonType property for a button on a form to "OK" its OnClick event will fire when the user presses Enter.

 on: May 06, 2019, 06:53:11 PM 
Started by rakesh - Last post by Derek Read
It seems odd that XMetaL 6 (I'm not sure which product) is running on Windows 10 without issue as that version (all products) was not tested on that operating system. All of the XMetaL version 6 products were released 5 years before Windows 10 was released. If anything I might expect the opposite of what you describe.

Please submit any files necessary to reproduce the issue to XMetaL Support together with detailed description where the files are placed, any specific configuration steps, an XML sample file, etc, so they can try to help.

Keep in mind that version 6 is not supported. It was tested on Windows XP but as Microsoft no longer supports that OS we cannot either. The first version to support Windows 7 was version 8. The first version to support Windows 8 was version 9. And the first version to support Windows 10 was version 11.

I'm not sure what any of this has to do with Page Preview, so if that is important please also include information about that in the description of the problem when you submit files to XMetaL Support.

Pages: « 1 2 3 4 5 6 7 8 9 10 »
email us