DP: I summerized the issue. I am not sure external people would be able to immediately understand the issue.
... Option 1. It makes the issue the responsibility of users.
... Conflicting names in the case of EXI.
... Option 2 is escaping.
... Option 3 is "keyname" element.
... Escaping is an option if it can be implemented very efficiently.
TK
TK: Don's option 0 seems to belong to option 1.
DP: Option 3 is the fastest because there is less work on decoder side compared with option 2.
... In Option 3, if we would need to define how the name should look like, then option 2 is attractive.
... Guidelines should be described regardless, I think.
... In HTML case, it uses escaping to render "&" character references.
<dape> NCNAME https://www.w3.org/TR/1999/REC-xml-names-19990114/#NT-NCName
TK: The encoder would need to check whether the characters fall into NCNameChar or not.
CB: Requiring all use cases to check the characters should not be necessary because the application already may have done sanitization beforehand.
... Most of the case option 1 works. If it does not work, option 2 gets interesting.
DP: If you know your application sanitized names already, can we indicate that in the root of the document that the names are all sanitized by application?
CB: If names are not sanitized, we can indicate that.
... By default, consider names are safe.
DP: Sounds like a very good idea.
... I would put a boolean flag just before every names.
... We may be able to express this boolean flag as an element.
TK: I will propose a method for escaping names.
https://lists.w3.org/Archives/Public/public-exi/2016Jul/0001.html
CB: We are not proposing option 2 is the only method.
DP: It depends on the use cases.
... We don't say users need to do this way or that way.
CB: If we can say it is an advice, that may satisfy JS.
... But DB may not be happy.
... Put it as optional. We can say it is a feature at risk.