Page 1 of 1

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

Posted: Sat Jul 31, 2004 23:37
by 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!

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

Posted: Sun Aug 01, 2004 00:20
by 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 :oops:

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.

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

Posted: Sun Aug 01, 2004 10:54
by 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...

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

Posted: Sun Aug 01, 2004 13:41
by CrazyEddie
I'm not sure what I think of this suggestion :lol:

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

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

Posted: Sun Aug 01, 2004 15:10
by 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! :D

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

Posted: Mon Aug 02, 2004 21:32
by 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.

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

Posted: Tue Aug 03, 2004 04:42
by CrazyEddie
No. The .xsd files are in CVS. Look in the ./XMLRefSchema directory. :)

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

Posted: Tue Aug 03, 2004 07:38
by spannerman
:oops: