Pages: 1 2 3 4 5 6 7 8 9 10
 on: Today at 08:34:53 AM 
Started by dmurphy - Last post by 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.

 on: May 21, 2019, 11:36:17 PM 
Started by claradsouza - Last post by claradsouza
Exchange EDB databases can develop corruption issues over time. IT admins often wonder what the best way is to prevent loss of information if at all such unfortunate incidents occur. The simplest to all such queries will be to use a too that can Convert EDB to PST.

There could be any number of reasons that can lead to Exchange EDB corruption like sudden shutdown, system failures, network issues, malicious software or even human negligence at times .  EdbMails is easy to use and the user needn’t be well versed in the intricacies of exchange server administration to be able to be able to recover exchange databases. Recover emails, contacts, attachments, calendars and even deleted items with ease using EdbMails.

The deep scanning algorithms perfected by EdbMails over the years ensure  that all tasks, journals,zip attachments,Inbox,calendars, or images are recovered safely.

Common exchange database corruption can be classified into two :

Logical : A logical corruption happens when a crucial bit of data is missing from the exchange database. It can lead to inconsistencies and make the whole database inaccessible.

Physical : Physical corruption on the other hand happens due to hardware failure, for instance hard disk crash.

Convert EDB to PST and perform quick EDB Recovery

It is by now clear from the facts stated above that one needs to utilize an exchange EDB to PST Converter tool to recover exchange databases from corrupt state. This is where – EdbMails – a one stop solution for all things exchange recovery, trusted by millions of exchange administrators across the globe comes in.

EdbMails offers support for Public and Private folder recovery and migration as well as archive folder migration. It also has support for Non-English Unicode characters and maintains the folder structure intact post  export. The data in the original EDB file is kept safe when using EdbMails. There is also support for direct migration to Office 365 and on-premise exchange server. Not only can you Convert EDB to PST using EdbMails, but there is also support for incremental EDB migration to Office 365 and Live Exchange Server.

Well if that isn’t enough, there is also a free trial version of the EdbMails EDB to PST Converter tool that can be used to test out all its features and even migrate upto 30 items per folder/mailbox to Outlook PST file.

For further details and download, make sure to visit :

 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.


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