Normative requirements for markup handling #586
Description
In #574, there was a discussion of the requirements for markup handling.
This issue is a placeholder to ensure that we consider and include the correct normative language for handling markup.
In part, I made this comment:
I wrote the above hurriedly yesterday, regretting "unsupported" even as I suggested it. I don't think it's necessarily "wrong" though.
The problem with markup is that we don't provide real support for it. It doesn't use functions per-se and we don't provide anything in the registry for it. Open/close don't mean anything, other than as semantic constructs--we don't require them to be in order or paired.
What we're doing is reserving syntax for a partially specified feature. I think there are three ways that implementations will respond to this: (i) they won't support markup; (ii) they'll provide "pass through" support for it using the data model and/or some other means; or (iii) they'll implement either specific markup support (such as for HTML) or some form of pluggable (generic) support.
All implementations can check the syntax of a placeholder and can resolve any variables. Therefore all implementations MUST emit a syntax error for a malformed placeholder and MUST emit a resolution error if they encounter one.
Let's consider an implementation that supports markup. I think we should provide support for implementers who want to put additional requirements on (specific) markup, such as requiring open/close pairing, requiring open/close to be in order, require specific options (or validate option values). Users will appreciate it if a typo in their markup produces an appropriate error (@stasm has cited this in the past). This suggests that we provide an optional MarkupError that implementations MAY emit.
What about pass through? I think this is what we currently describe, albeit we require formatToString to remove the markup (pass through is to the data model or parts. Here we might want to relax the requirement to allow implementations to decide how to pass markup through (callers might need to reparse the output as a result).
What about non-supporting implementations? They might still emit data model parts or they might eat them. I think we might want to require that they not fail on markup but permit them to not emit the markup.
A key consideration is not to allow markup to become a security attack vector. We don't want <scr{#bad}ipt> to become a script tag (or other abusive sequence) in ways that are hard to detect. This can happen if the markup doesn't collapse to nothing until late.
The last two considered together might look like:
- An implementation SHOULD NOT emit the markup placeholder when formatting to string.
- An implementation MAY (SHOULD?) emit unrecognized markup placeholders in the data model (i.e. they do something other than formatToString)
- An implementation SHOULD NOT apply any additional validation (beyond syntax and resolution) to unrecognized or unsupported markup.
- An implementation MAY emit a MarkupError for unrecognized or unsupported markup. (this has to be allowed if implementations that support markup are to identify typos)