as reported in july, martin dürst and i have been working on a fragment identification scheme for plain text documents. the idea is that by appending such a fragment identifier to a URI identifying a plain text document (
is an example), it is possible to identify only a fragment of the complete document. as of today, the latest version of the draft has been placed in the RFC editor's queue, which means that it will be published as an RFC pretty soon. here is the draft's abstract:.../ht05-abstract.txt#line=5,10
This memo defines URI fragment identifiers for text/plain MIME entities. These fragment identifiers make it possible to refer to parts of a text/plain MIME entity, either identified by character position or range, or by line position or range. Fragment identifiers may also contain information for integrity checks to make them more robust.
amaya already implements this functionality, and i hope that other browsers will soon follow. one thing i would like to see is fragment-based inclusion into HTML, and this could easily be implemented in some JavaScript library. this way, it would be possible to create an HTML page which dynamically includes parts of plain text files, for example some log files, and this scenario might be useful for assembling Web-based status overviews.
another thing i would like to do is adding plain text fragment identification to XIPr (an XSLT implementation of XInclude), so that in the same way as XInclude allows the inclusion of XPointer-identified XML fragments, it would also be possible to include plain text document fragments. this shouldn't be too hard, given that we finally removed the rather complex regex functionality from the draft and all that is left now are character- and line-based fragments.
this means the specification has become pretty simple (after it started out being much more complicated), and i believe that the simplicity increases its chances of success. on the other hand, fragment identification never interested many people on the web anyway, and therefore i assume that by and large, this little building block will go unnoticed...
Now published as RFC 5147: http://www.rfc-editor.org/rfc/rfc5147.txt
Posted by: Stéphane Bortzmeyer | Thursday, April 10, 2008 at 04:36