Bad things happen when .xsd gets out of date with code

[Sinbad]

I don't know if there's much you can do about this, but this just chewed me for an hour so maybe it'll just help someone else out

As the title suggests, if you don't make sure that the .xsd your app is picking up is totally in sync with the CEGui code you're using, you can have problems. In my case, it was 'Unexpected error when parsing font..' - this was because the attribute 'AntiAlias' had been added, and my .xsd did not include it (neither did my font XML). It's my own fault, I should have kept everything in sync, but I can imagine people may also hit this.

If the .xsd is out of date, the validation does not happen, and when the code tries to access this attribute, it throws an exception, although I'm not sure what. It's not a SAX / XML exception, or a FileIOException which are the only types documented as being thrown by SAX and in the CEGui code. This made it a little hard to track down - I eventually just put breakpoints all over the XML handler code and stepped through it all.

The moral of the story is - if you update your CEGui DLLs from CVS, make sure you update the .xsd files too!

[CrazyEddie]

Now the really funny thing about this whole thing is that after I added that new option yesterday, when I started testing, I spent quite I while going back over the code looking for what I had broken before I realised that the xsd in the test app project was out of date

These files will not change too often though. There is currently only one more planned change to any of these files coming up (GUIScheme.xsd to allow widget type-name aliasing).

For future changes I'll post an item on the front page reminding you all to update

Edit:
The exception should only really be a FileIOException, I'll look into this next week and see what's going wrong if that's not the case.

[sazzer]

Is there any way that the XSD files can be included in the code itself and not need to be a seperate file? Obviously the code knows when your loading a font or a schema or whatever so can it not inline the XSD to Xerxes so that it's always up-to-date?
I've never used Xerxes myself so I don't know if this is possible, but it would remove one point of difficulty in upgrading versions...

[CrazyEddie]

I'm not sure what I think of this suggestion

It would certainly alleviate the problem of having the wrong .xsd files. I'll have to have a think about it and make a decision

[Sinbad]

This would be ok, so long as there was also an external version which was identical that you could examine to know what you're allowed to do, or better yet use in an XML tool.

@CrazyEddie: I'm glad I'm not the only one to make that mistake!

[spannerman]

Im getting the same problem. Eddie, do the new VC dependencies packages include the correct/new XSD files? I think I'll give them a shot.

[CrazyEddie]

No. The .xsd files are in CVS. Look in the ./XMLRefSchema directory.

[spannerman]