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

improve handling of invalid XML documents #14

Open
taveras opened this issue Dec 11, 2017 · 2 comments
Open

improve handling of invalid XML documents #14

taveras opened this issue Dec 11, 2017 · 2 comments

Comments

@taveras
Copy link
Contributor

taveras commented Dec 11, 2017

per @johnkpaul 's suggestion, we should refine the behavior when faced with an invalid XML document.

today, XMLToReact#convert will simply log a warning when supplied with an invalid XML document. it will also log the warning for all xmldom error levels.


Here are a few questions around this:

  • How should we handle the three xmldom error levels (warning, error, fatal)?
  • Should we strictly throw an error when coming across an invalid XML document?
  • Should we have a 'quirks mode' option with forgiving parsing, similar to HTML parsing?
  • If yes to the previous question, should we be in 'quirks mode' by default, and have an opt-in 'strict mode'?
@johnkpaul
Copy link

My higher order feedback is that whatever decision is made as to the behavior on invalid input is clearly documented and not surprising to a user of this library.

With respect to your questions in particular, I'd say what are the actual needs of Muse? When you have a business user typing their own XML and they make a mistake, which one of these options would you prefer?

Other than clearly documenting, IMHO, you don't need to add any special and extra features just because it's being open sourced.

@pgoldrbx
Copy link
Contributor

pgoldrbx commented Dec 19, 2017

Generic parsing and handling can go here; anything specific to an application should live downstream.

As for whether we throw or simply log errors (and pave over them) could be configurable. My instinct is to throw and let the application decide what to do.

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

No branches or pull requests

3 participants