mbakeranalecta
commented
6 years ago It strikes me that error recovery only really makes sense in a media domain or document domain language in which there is a presumption that all element content is intended for display. It is inappropriate for subject domain and management domain languages (and for any document or media domain language that contains any management domain structures) since recovery could result in the display of content that would be misleading, incorrect, or even private. Since SAM is intended primarily for subject domain use, strictness seems to be more desirable than leniency.
Also, in SGML, error recovery was largely about assuming end tags that were missing. Trying to do that in a language where structure is based on indents seems fraught with peril.
Rejecting and closing.
Currently, the parser in batch mode will recover is there is an error parsing one file and will report the number of errors at the end of the process. However, as of 828ef33d291f1364a6edf036588ac5f21fac0abb, errors in processing includes are fatal errors. This means that they will be reported in batch mode, but will shut down all parsing in single-file mode. If we want to be more forgiving, allowing the including file to continue parsing if there is an error in the included file, we need a new class of non-fatal error.
Not sure if there is a real reason to implement this, but one complaint about XML is that the parser is (by law) not allowed to do error recovery and continue. It must report the error and stop. Some would like more lenient behavior.
The counterpoint to this is that such leniency only really make sense to final display to the end user. For any stage of development you want to error so you can fix things. But in a dynamic delivery scenario, you might want back end processes to be able to recover and continue for the sake of the downstream display.