I've come to really appreciate the difference between "syntactically correct" (ie: is a file valid xml) vs "semantically correct" (ie: does it follow a specific

I've come to really appreciate the difference between "syntactically correct" (ie: is a file valid xml) vs "semantically correct" (ie: does it follow a specific dtd if it's valid xml.) More than that, I've come to realize how many other people don't have this appreciation even though they will identify problems that directly relate to this distinction in every day usage. To truly be able to have a portable file format, there needs to be a way to do both validations reliably in different contexts (eg: different languages). If you ignore this part of your design then it may become the slowest part of the eno ecosystem because your grammar will have quirks that you'll end up needing to support long-term. I suggest toying with this functionality now and providing something which is extremely pessimistic on what it will pass. Only loosen things up as people show a need and keep your entire spec as tight as possible. I would imagine that you could even use eno syntax to describe document structure, much like xml/dtd has such strong parallels with each other. Then you get the fast parser in both places essentially for free! Finally, on the format of eno itself, I'm curious on your thoughts relating to unicode characters that visually masquerade as common characters. eg: http://www.fileformat.info/info/unicode/char/ff1a/index.htm http://www.fileformat.info/info/unicode/char/ff1a/index.htm Sample usage: --- author： Jane Doe email： jane@eno-lang.org --- Does this parse? How about this: --- author： Jane Doe: email： jane=doe@eno-lang.org --- What do I do if I want a "#" in a name? --- # #twitter @hackernews = 0xC0FFEE --- or: --- # \#twitter @hackernews = 0xC0FFEE --- Are quotes optional somehow? Can I put arbitrary things into an identifier? Cheers and keep up the great work!