dokieli
dokieli copied to clipboard
linkeddata
self-contained documents
It should be possible to bundle up an entire document into a single file that can then be displayed offline.
Creating a zip file for the document is not adequate, unless there is a simple way to display the zip file, i.e., without first having to unzip.
Ideally all one would have to say would be open <filename> to display a document in one's browser.
Marking it as a feature/enhancement. Why does it need to be "bundled" into a single (executable?) file? If the desire is to do offline reading, it can still be achieved with multiple files e.g., directory with the files, and the author/reader only needs to load the HTML e.g., firefox index.html.
The file doesn't have to be executable.
However, you want to match the ease-of-use of PDF files, where you don't need to do any packing or unpacking. All you need to do is to download a single file and then open that file.
It may be that you can't do this with HTML. If so, that's yet another failure of HTML.
- Just because the toolchain around PDF does something, it doesn't follow that this project or any project must follow the same set of design patterns, features, use. None whatsoever. You may wish that as a feature (and it may very well be a desirable thing), but that's the most one can say. It certainly isn't something that must be done.
- Technically, it is achievable in HTML. One would simply need to include all of the CSS and if any JavaScript internally
<style>,<script>. Images can also be included as a data URI.
So, certainly not a "failure" of HTML for something that you want. Just because it can be done, it doesn't mean it is a good design pattern. :)
Having said that, I'd like to leave this issue open for future investigation. It should be simple enough to write a shell script to include all CSS, JavaScript, and images in the HTML so that it can be bundled for those that would like to share the document as such. For making the document public on a Web page, this is not really desirable.
Ease of use is a vital aspect of document dissemination. If it is harder to send around HTML-based scientific documents, then a lot of people just won't do it. It's not just PDF that has this desirable characteristic. Word and many other document presentation systems also work this way.
Even for viewing over the web, a single-file format can be preferable. I often run into situations where I am viewing an HTML document and a referenced file doesn't load.
That's all valid and point taken, however, it is not an either or case. From the point of modularity and scaling, bundling everything doesn't make sense. But, like I said, it can be technically achieved. I presonally don't think it should be the first thing to run after because we have more use-cases to cater.
EPUB is designed for packaging HTML into a single file: HTML + CSS + friends in a single tasty ZIP package.
I think @jodischneider 's EPUB suggestion addresses @pfps 's initial issue.
I still see this issue as a feature to satisfy those that require packaging X (e.g., EPUB) and that should be up to the author to decide if and how they want to package (i.e., there may be other technologies that's preferable for packaging and transporting). As a subject inside an EPUB or ZIP file can't be linked to (i.e., there is no URI to point which satisfies 1) EPUB file on the Web, 2) a file inside EPUB 3) a subject or a fragment inside that file) from the outside, it doesn't play along with the rest of the Web/Linked Data stack. So, EPUB is not well-aligned with what I think as "Linked Research" e.g., I can't link to a variable inside your hypothesis in your EPUB file. If that's possible, then this issue can be handled as a feature. EPUB is just a data dump even though it may satisfy supposed ease of transportation and rendering on a finite list of devices.
The EPUB method is a full solution ONLY IF the result can be viewed as easily as PDF and WORD files can be viewed. That means without having to load special software and without having to first unzip.
Yes, there are various software packages that do this. Unzip is not needed.
Some examples: http://www.epubread.com/en/ https://booki.sh/
Or a list here: https://en.wikipedia.org/wiki/EPUB#Software
On Sat, Nov 8, 2014 at 3:43 PM, Peter F. Patel-Schneider < [email protected]> wrote:
The EPUB method is a full solution ONLY IF the result can be viewed as easily as PDF and WORD files can be viewed. That means without having to load special software and without having to first unzip.
— Reply to this email directly or view it on GitHub https://github.com/csarven/linked-research/issues/15#issuecomment-62278042 .
dokieli has a "Save As" feature which goes through the process of fetching all dependencies and putting them to target location. I think if we introduce the following, this issue could be addressed to a reasonable degree:
- Offer a checkbox along the lines of making it 'offline-friendly' or 'self-contained'
- Once the dependencies are fetched, update the document to inline everything (eg. data URIs for media where possible, embed scripts...)
It may not be perfect eg. a script may be dynamically calling other scripts or APIs, or even media that's large in size that may not be ideal (realistic?) to store, but it may put things in motion that's useful enough.