the name in the end tag of the element must match the element type in the start tag error

Anonymous
2010-10-28T11:18:41+00:00

I too am having the problem many people seem to be having on this forum. I have created a fairly large and important document which includes a lot of maths equations and some graphics. Now every time I try to open it it says there is an error with a mismatch between the start and end tags. I have never worked with XML but have tried to find what feels like a needle in a haystack and can't really see how to proceed. Is there any chance you could help? I have uploaded the document to:

http://www.sendspace.com/file/0ecfpu

Many thanks,

Andrew

Microsoft 365 and Office | Word | For home | Windows

Locked Question. This question was migrated from the Microsoft Support Community. You can vote on whether it's helpful, but you can't add comments or replies or follow the question.

0 comments
Answer accepted by question author
Anonymous
2010-11-01T19:04:17+00:00

Hi Andrew,

The fixed file is at http://www.wordarticles.com/temp/AH%20Statistics%201%20Notes%20-%20Outcome%202.docx

To try to answer your questions:

There is no easy way to do it in Notepad - I generally use Visual Studio; Yves Dhondt - the only other person here, AFAIK, who fixes these documents - has some tool he wrote himself. It isn't very difficult but there is no guarantee of what you will find when you look. Usually - and I'm sure you're right - it happens when equations and graphics are together and an oMath end tag, and perhaps part of the equation it ends, gets misplaced within a structure that is meant to enable the equation be correctly displayed in earlier versions of Word that do not support the new equation engine.

The structure should be:

<mc:AlternateContent>

<mc:Choice>

<m:oMath>

Start of equation

End of equation

</m:oMath>

<mc:Choice>

<mc:Fallback>

Probably some graphics

</mc:Fallback>

</AlternateContent>

but ends up as:

<mc:AlternateContent>

<mc:Choice>

<m:oMath>

Start of equation

<mc:Choice>

<mc:Fallback>

Probably some graphics

</mc:Fallback> </AlternateContent>

End of equation

</m:oMath>

This is a bug so nothing is for certain, and I don't know what circumstances trigger it, or what you can do to avoid it. I also don't know if Microsoft are working on it, although I have informed them and they have replied that 'it has been passed to the appropriate team' or some such.

For my own amusement I am working on an AddIn that will attempt to mend these documents but I don't know how well it will work, yet.

Enjoy,

Tony

www.WordArticles.com

Was this answer helpful?

8 people found this answer helpful.
0 comments

207 additional answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Anonymous
    2010-11-29T14:15:55+00:00

    Certainly I've seen files with the central directory missing, but that can often be rebuilt, allowing at least partial recovery. I've also seen quite a few files with a block starting at 0x800 having been overwritten, which has wiped out the crucial begining of the document.xml part - the sine qua non, but it is also the largest part so the most likely to be damaged.

    I think you are being very kind to Microsoft to suggest there is any rationale to the ordering of parts <g>, I am prepared to believe that there may be a reason for the position of the properties parts - in the same way that the Summary Information streams of the old compound binaries were at the end of the file, but overall I doubt there was any strategy. The standard does not impose the order, so it could never be relied upon anyway. Mind you, the standard does not impose (many) part names, but you try creating a document where the document.xml part has a different name.

    As for the growth mechanism, I'm afraid I just think it's totally misplaced - as out-of-date as the old fast save mechanism - and should not have been included in the standard. And I doubt the benefit to be gained from not, in theory, having to rewrite the whole file would be significant on computers equipped to run the applications, and would be offset by the potential for error in keeping track of what had, and had not, changed.

    Enjoy,

    Tony

    www.WordArticles.com

    Was this answer helpful?

    0 comments
  2. Anonymous
    2010-11-29T12:55:46+00:00

    I noticed that it always seem to be the central directory and the last few files which seem to be corrupt. Most likely this is indeed the result of a (failed) delayed write to external media.

    Unfortunately, Microsoft tends to put the document.xml file, the most important file in the archive, towards the end thereby making the document 'less' recoverable in my opinion. If document.xml would be the first entry in the archive, I'm convinced that more documents would be recoverable. Losing styles, settings, metadata and perhaps even some graphics is less of an issue than losing the actual text.

    I always wondered why Microsoft made that decision. The only 'sensible' reason I could come up with is that it limits the need to rewrite the entire archive whenever you change something to your document. The beginning of your archive (metadata, settings, ...) doesn't change all that often, so no need to rewrite it. But then again, they did introduce the in-place growing mechanismn which they don't use (well they introduce the overhead but don't reap the benefits when they can) but which could solve some of these issues (e.g. only require a complete rewrite every 4th or 5th save operation).

    Was this answer helpful?

    0 comments
  3. Anonymous
    2010-11-29T11:50:03+00:00

    The problem with zip files is not really a Word issue, per se - it usually happens when Word documents have been saved direct to USB sticks - but the end result is that some, often all, of a document is unrecoverable.

    Enjoy,

    Tony

    www.WordArticles.com

    Was this answer helpful?

    0 comments