Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Input -> Parser -> Writer = Input #8

Open
wilzbach opened this issue Jan 28, 2018 · 4 comments
Open

Input -> Parser -> Writer = Input #8

wilzbach opened this issue Jan 28, 2018 · 4 comments

Comments

@wilzbach
Copy link
Member

From @burner on July 13, 2016 14:22

Test if the above shown chain yield an output document where the content is equal to the original input.

Test that with all combinations of lexer, parser and writer.

Copied from original issue: lodo1995/experimental.xml#23

@wilzbach
Copy link
Member Author

From @Hackerpilot on July 15, 2016 21:4

xmllint's --format option can be used to standardize the formatting of an XML file so that you can use diff. This may simplify writing the tests.

@wilzbach
Copy link
Member Author

From @lodo1995 on July 15, 2016 21:16

@Hackerpilot thank you.
This will prove very useful, as it will allow me to test on the entire W3 Test Suite without worrying about formatting issues.

@wilzbach
Copy link
Member Author

From @lodo1995 on August 17, 2016 12:6

@burner Great news!
I had to change the way <!DOCTYPE nodes are handled, but now the library can input and output them easily. This was the only thing that prevented input -> parser -> writer = input to be tested.
Now make test (test driver at source/test.d) runs the chain on every valid file of the W3C XML Test Suite.
Currently the reported failure rate is ~11%, due to the fact that we don't preserve any whitespace, while xmllint preserves some of them (even if all files are normalized with options --pretty 2 --c14n11).

@wilzbach
Copy link
Member Author

From @burner on August 17, 2016 19:43

sweet! Awesome job.

If you have the time, maybe just compare the nodes and there attributes. That might give you a more realistic failure rate, but only if you have time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant