XSD support in mapper/config XML

[harawata]

A fix for #1193 .
Mostly @kazuki43zoo 's work. :D

By setting system property org.mybatis.useXsd to true, users can use XSD instead of DTD when writing mapper/config XML.

<mapper namespace="org.apache.ibatis.builder.xsd.AuthorMapper"
  xmlns="http://mybatis.org/schema/mybatis-mapper"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://mybatis.org/schema/mybatis-mapper http://mybatis.org/schema/mybatis-mapper.xsd">

<configuration xmlns="http://mybatis.org/schema/mybatis-config"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://mybatis.org/schema/mybatis-config http://mybatis.org/schema/mybatis-config.xsd">

Migration steps would be....(just an idea)

1. In version 3.5.0, keep DTD as the default.
2. In version X (when some XSD-only enhancement is added?), change the default to XSD and output a log message (INFO or WARN) like DTD is deprecated, to use XSD, see ... to encourage users to migrate to XSD..
3. In version Y, remove DTD support.

@jeffgbutler ,
This may affect Generator in some way.
Please let me know if there is any concern.

[jeffgbutler]

I think there would only be a generator impact in your "version Y" when DTD support is removed. Also, the newer code generated for my MyBatis Dynamic SQL library doesn't use XML at all, so no issue there. I'm OK with this change.

[harawata]

Thanks for the comment, @jeffgbutler !
Let's test this in the snapshot, then.

[jeffgbutler]

I haven't reviewed this code (sorry) - but I have a question...is it really necessary to have the system property? Can the code be written such that MyBatis will parse the file if either XSD or DTD is used?

[harawata]

@jeffgbutler ,
I couldn't find a way to achieve it.
Any approach we should try?

[jeffgbutler]

I don't have much of an idea. I suppose you could try DTD and if it failed, fall back to XSD. But that seems kind of kludgy.

[harawata]

I tried that approach, but it wasn't possible to re-read the Reader/InputStream unless we put the entire file content on memory.

I then tried to find a lenient way to parse both XML using the same code, but couldn't find any.
It is possible that I have missed it as there are many different way to parse XML, though.

[harawata]

@jeffgbutler ,
We're approaching the release of 3.5.0.
In case you are still unsure about this, I am totally fine with reverting the change and pushing the XSD support to a future milestone.
If there is a way to remove the system property, I would be more than happy. :)

[jeffgbutler]

I haven't had time to look at it, so don't hold up the release for me.

My only idea is as I said above - try it one way and if it fails try it the other way. This would mean reading the file twice, so then I could imagine a property like "preferXsd" which isn't any better.

I will say that Spring supports both ways without a property - so it must be possible. Not sure how they do it.

[harawata]

Thanks for the comment, @jeffgbutler !

The problem is that it is InputStream that is passed around in the current implementation.
And there is no good way to read the same InputStream twice without storing its content on memory.

Spring seems to use org.springframework.core.io.Resource as a parameter to avoid this problem.

https://github.com/spring-projects/spring-framework/blob/109552d86853bbf4b026bd556842f7ffa78d281b/spring-beans/src/main/java/org/springframework/beans/factory/xml/XmlBeanDefinitionReader.java#L461-L495

It would be possible to change MyBatis implementation, but the impact won't be small.
Rather than delaying 3.5.0 release, I would revert this PR and revisit the new approach later.
This change by itself provides no advantage anyway.

@kazuki43zoo ,
What do you think?

[jeffgbutler]

@harawata +1 on revert/delay. I'd rather we solve this in a more Spring-like way, but don't need to delay the release for that.

[kazuki43zoo]

@harawata @jeffgbutler I agree!

[harawata]

Reverted. Thank you for the comments!