XSD Validation and empty markup

I need to read through your investigation more closely to understand what is going on (it has been a year since I last looked at that part of code), but you are probably right in that code is not working the way it should. I thought I had tested empty elements properly (with a unit test), but perhaps this is not the case. A unit test to demonstrate the prob,em would be useful.
Btw, one minor comment on empty elements – I think that empty CDATA is NOT allowed within empty content specification, as per xml specs; at least it is not for DTDs (nor are processing instructions or comments). This assuming that xml schema has not changed this definition. But other two forms should of course be valid.

As to call to validateEndElement: that is not completely safe, since it updates state of legal textual content (any text fine, specific textual content, none), and omitting the call would make these values go out of sync. This may work for some cases, but in general could cause problems in other places. It is possible that in your case it would – so for now maybe that is the work-around.

Finally, thank you for trouble-shooting this: schema validation part has not been extensively used so far, I think, and thus there are more potential problems to uncover. But MSV (the validator being used) should not have too many bugs, so we should be able to straighten out these problems.

One request: can you attach the test schema you are using? I can write a simple unit test to check out the problem then.

I'm sorry it would be difficult, however I can provide another one similar. However I need to check if the probleme will still be there with this file, which would normaly does. I'll keep you in touch tomorrow (10:30 pm here ^^)

Thank you very much for your time !

Sure: no need to be exactly the same, just needs to reproduce the problem.
I tried a very simple example (with regular text, empty tags), but that worked as expected.

I have done the test with a minimal XSD file and a minimal also xml file.

I have the following result :

11:16:23,533 [ERROR] xxx.Import$ImportOfferXMLReporter - XSD Valition : Unknown reason on line:6 col: 2
11:16:33,018 [ERROR] xxx.Import$ImportOfferXMLReporter - XSD Valition : Unknown reason on line:7 col: 15
11:16:33,752 [ERROR] xxx.Import$ImportOfferXMLReporter - XSD Valition : Unknown reason on line:8 col: 27

For now, I will comment the line reportError(mErrorRef); in GenericMsvValidator.java, hopping that will not desactivate too many errors.

Thank you.

Simple test files.

Ok, yes, I can reproduce the problem. Seems to have something to do with the restriction – unrestricted xs:string works ok, but somehow restricted one which also should does not.
I think I will need to contact Kohsuke (author of MSV) to see if he has an idea as to what might be happening.

Btw, you could also just consider making listener ignore these messages (based on descrption of "Unknown reason") – as long as listener does not throw an exception, things should continue working, The main reason for considering this is that you wouldn't have to modify woodstox sources.

I sent a message to msv users list, and hope to hear back from Kohsuke. Something funny is going on with integration of MSV and Woodstox, I think, since MSV command-line tool is ok with the content.
My suspicion is that maybe MSV acceptor might expect a dummy empty string call for such elements. But that wouldn't explain problems with CDATA.

Also: regarding the call to validateEndElement: that is actually correct, and needs to be done to make "<element/>" appear same as "<element></element>", which are logically equivalent. Without such call, validator would not see the "virtual" end tag. So the call has to be done at that point.

Ok, thanks for the explanation with the "<element />" and validateEndElement. I've tried to comment it, and it was .... no so good xD
I'm hoping the project msv is still alive

Yes may be it will ignore the unknow errors in the listener, but i have no problem overriding just one class of the project woodstox in my project. Still, thank you for the tips anyway.

Think I figured out the problem: MSV does indeed expect a call to 'validateText', even if content is missing, if there is a restriction. So I think I can get it fixed quite easily after all.
I also think that your original point was valid in that call to validating end element should be done at bit later point – this way the exception is not thrown right away, when seeing empty element (and hence it is possible to get start-element info and such), but only when iterating to get the matching END_ELEMENT. Minor improvement, but correct one to make I think.

Ok, I fixed the problem. Will be part of 4.0.3 release and 5.0 snapshots, integrated to 4.0 branch and trunk.

That's a great news. Thank you !

Included in 4.0.3 release.