Replace "parse error" with "parse violation"

[sideshowbarker]

The spec should replace https://url.spec.whatwg.org/#parse-error with parse violation.

parse error is an ambiguous and misleading term. See #59 (comment) for background.

[hillbrad]

Perhaps just adding "and continue" or some other language to indicate that the algorithm "falls through" such a condition would be a more important clarification.

[annevk]

I'm a bit stuck on how to satisfy @hillbrad's comment since we have many instances where we require that something is done, but don't want things to end. If we make it "report a syntax error" would that make it clearer that it doesn't terminate the parse operation? Note that the definition for parse error is clear on this already.

[hillbrad]

I see the difficulty here. I wonder if there is room to introduce a
distinction between a "warning" and an "error"? I tend to think of a
warning as something that may / should be reported but which doesn't cause
termination, whereas an error has stronger connotations of being unable to
recover or continue an algorithm. Not all that important at the end of the
day, I should have been a more careful and complete reader.

On Fri, Aug 14, 2015 at 4:45 AM Anne van Kesteren notifications@github.com
wrote:

I'm a bit stuck on how to satisfy @hillbrad https://github.com/hillbrad's
comment since we have many instances where we require that something is
done, but don't want things to end. If we make it "report a syntax error"
would that make it clearer that it doesn't terminate the parse operation?
Note that the definition for parse error is clear on this already.

—
Reply to this email directly or view it on GitHub
#60 (comment).

[annevk]

Yeah, I think that's why @sideshowbarker suggested "violation". It's not clear to me that "warning" is strong enough since you are actually in error, at least, to the extent we keep caring about conformance.

[sideshowbarker]

I think syntax violation is perfect in the context of the URL spec but I think optimally it would be good to have the same term for this “parse error” stuff across all specs, including the HTML spec. But in the HTML spec, since the treebuilder part (not just the tokenizer) also contains “parse error” cases, syntax violation may not be accurate for in all those cases.

But I guess we can worry about what to change it to in the HTML spec if/when we ever actually get there.

[annevk]

Yeah, I wonder what errors there would not be syntax violations, but I agree that if we find we need a different term we should revisit this.