Slightly related (if you hold your head at the right angle) is the (commercial) platform called NetKernel. It brings URIs into conventional programming scenarios, presenting something like a RESTful programming language. (Whatever that might mean...)
I haven't done anything with it, but I find it fascinating just to read the documentation:
Because they originate from a time where plain text was what you had, and the format was created to be consistent and easy to format by hand. I still prefer my specifications to be in plain text so that I can view them easily and quickly.
It would be easy enough to at least format them in HTML, they use such consistent ascii 'typesetting', it could easily be automated.
I mean, they are formatted in HTML now, but as a giant block of monospace text. They could use <hx>s for the headers, let the text flow with browser resize for small screens, heck use bootstrap for good readable web typesetting, etc.
I am not sure why the IETF isn't interested in better web typesetting for em.
At one point someone had a site that did that, I think it was advertised and discussed here on HN, but I forget what it was called, and I think it faded into non-supported obscurity (since it was obviously a labor of love, unpaid).
Note: most RFCs can't be prettified at the moment, as their
source files are unavailable to the public and need to be
requested from rfc-editor.org. I'm working on this.
Very helpful, thanks for link. I'm working on my own web app "framework" and had rolled my own URL/URI router. This will reduce my reinvention quotient.
It's pretty great to have a standard for templates to generate URIs, but it's equally important to parse URIs and extract the variables. It looks like this RFC skimps on that part:
In Section 1.4:
Some URI Templates can be used in reverse for the purpose of variable
matching: comparing the template to a fully formed URI in order to
extract the variable parts from that URI and assign them to the named
variables. Variable matching only works well if the template
expressions are delimited by the beginning or end of the URI or by
characters that cannot be part of the expansion, such as reserved
characters surrounding a simple string expression. In general,
regular expression languages are better suited for variable matching.
It'd be better IMO to have a stricter definition of parseable templates and include test cases so that implementations that try to validate templates for parseability don't disagree.
20 comments
[ 5.6 ms ] story [ 49.0 ms ] threadI haven't done anything with it, but I find it fascinating just to read the documentation:
http://docs.netkernel.org/book/view/book:quickstart/doc:quic...
[1]: http://tools.ietf.org/tools/rfcmarkup/
I mean, they are formatted in HTML now, but as a giant block of monospace text. They could use <hx>s for the headers, let the text flow with browser resize for small screens, heck use bootstrap for good readable web typesetting, etc.
I am not sure why the IETF isn't interested in better web typesetting for em.
At one point someone had a site that did that, I think it was advertised and discussed here on HN, but I forget what it was called, and I think it faded into non-supported obscurity (since it was obviously a labor of love, unpaid).
http://tools.ietf.org/html/rfc6902
In Section 1.4:
It'd be better IMO to have a stricter definition of parseable templates and include test cases so that implementations that try to validate templates for parseability don't disagree.