This is an attempt to simplify the conversation, moving away from specific examples and technical terminology. If it just adds complexity, let's pretend I didn't say anything. My basic summary as I think that Ivan's earlier definition of "portable" is just fine. ;) A Web Document consists of: 1. Content, that is 2. Encoded in some format "Content" might mean text, captions, a video, a visualization, data, math, musical notation, the smell of cloves in a mug of cider on a winter morning. "Encoding format" might mean PDF, plaintext, HTML5, Epub, SubRip, AVIs, OGGs, Flash, WMV, MathML, LaTeX, Sibelius, FragrenceML, etc. Certain elements of a web document sit on a wobbly line between "content" and "encoding format," such as fonts. When a web document is *portable*, that means that the object being described as portable: * Given a toolset which can render all the encoding formats, * But in the absence of any other web resources * Can display its all of its essential content. This is still wobbly, to be sure. For example, as Leonard has been pointing out, caching is a thing. But I think -- staying away from the discussions of specific technological caching solutions, which are relevant to defining "portability," -- a web document which contains enough of its remote content cached to be displayed in the absence of other web resources is portable *only with that cache*. That is to say, the "portable web document" is the web document + cache. A web document that has the potential to be cached but has *not* been is not portable; it has non-portable dependencies. But I think that this should resolve the questions of leaving it to open-ended or too specific. Because we are not addressing specific technologies, we can just say that any aggregate whose content is portable is itself portable. (Again, if this adds more confusion, let's pretend I didn't say anything. I'm trying to synthesize, not add more chaos. I did enough of that in the other thread.) Deborah
Received on Thursday, 10 September 2015 18:51:33 UTC