Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
Symbol encoding strategy and capitalization #461
In this pull request, I am proposing a few modifications to the generation of classes from an XSD:
This PR breaks compatibility with v1.5. In particular:
Sorry about the late response.
Hi, @eed3si9n. Apologies for the late response; time zone difference meant I had started my weekend! :)
ScalaXB 1.5.2 generates class names that look like
My initial suggestion is to replace these punctuation characters with their names, e.g.
I understand that this change is backwards-incompatible but I think it's a step in the right direction.
What do you think?
This changes the behaviour of trailing underscores which used to be encoded as `u93`. They are now encoded as `u95`.
…ss names Pass "discard-non-identifiers" to enable this option. Known issue: if the option is enabled and an identifier ends in multiple underscores (e.g. `el__`) then the generated name will be invalid (`el_`, as only the last underscore will be dropped).
* discard-non-identifiers: Add an option to discard non-identifier characters from generated class names Unify the logic to generate "u1234" when identifiers include symbols
… symbol's name According to the XML spec, permissible symbols are colon (`:`), dot (`.`), hyphen (`-`), and underscore (`_`). There is no test case for colons because Scala XML has a hard time dealing with them. (scala/scala-xml issues 94 and 182)
Previously, any non-latin-word character would have been encoded into uXX. This change enables ScalaXB to accept all characters that are valid in a Java identifier.
…cters Previously, such characters would be encoded into `uN` where N was the decimal numeric value of the character. The new implementation encodes them as `U0000`, where 0000 is replaced by the zero-padded 4-digit hexadecimal numeric value of the character.
@eed3si9n: I have updated this PR to include my other PRs with a feature flag for each behavioural change. I'll close the other PRs.
The difference between the output of v1.5.2 and this version with arguments
Hopefully, these two parameters can become the default in v2.0.
I've added a final commit to add keys to the sbt plugin so that it has the same configuration options as the CLI app. Unfortunately, the sbt-test fails to compile on Travis CI because it isn't using the keys that are defined in the same commit. Is this something you can help with, @eed3si9n?