Sequentia

2004-11-19 : These are design notes. I had a bunch of stuff in my head this morning, and right now it's all gone vague and disorganized. Feh. Hopefully it will come back to me as I type.

The Problem

I would like to create something to make it easy to present web comics.

Goals / Forces To Resolve
Design

Concepts:

XML is convenient because it allows freeform data when necessary. This would make adding the resources to the node easy. Plus you could use XSLT to transform the resources for a node to produce the view. I like the idea of adding a standard mechanism for indicating that the contents of an XML element is actually located in another file. That could make updating much easier and reduce contention should there ever be a significant number of updates.

Need to define a standard file layout, and standard elements and attributes. For example, the date mapping should be standard so that a common calendar control can be used. Similarly partition information. There should be a standard way to indicate the preferred view transform for a node (so that one node with an unusual layout can be handled easily), and possibly the preferred view transform for a repository or a sequence (so that the standard transform doesn't have to be specified in every node, only the special cases). Also, node name, for index views.

Need to define the standard components and views. For example, Full page w/ prev, next buttons. Calendar view. TOC/index view. Hierarchical locator dropdown.

Some of the desired functionality would be better represented in a full programming language like Java, but access to such is difficult from within web pages. There are multiple standard for web site scripting (ASP, PHP, ASP.Net, JSP) which means that, for example, if significant effort was spent developing an ASP implementation, it would not be "commercializable" to a site based on PHP.

  • Need to research of there is something like an easy way to invoke Java from both ASP and PHP.

    {repository}
      {sequences}
        {sequence id="main"}c1p1 c1p2 c1p3 c1p4{/sequence} {!-- how should this be delimited? --}
      {/sequences}
      {transforms /} {!-- bind transform names to xlst files, etc. --}
      {nodes}
        {node id="c1p1" date="19990909" title="The Fun Begins"} {!-- id used in sequece; 
                        standard date mapping?; title used in TOC? --}
          {altTransform use="pageWithComment" /} {!-- identify a custom transform by name; 
                                                      may also specify xslt file, etc. --}
          {img id="main" src="chapter1\pg1.gif" width="700" height="500" /}
          {comment src="chapter1\pg1.txt"}
          {img id="thumb" src="chapter1\t-pg1.gif" width="70" height="50" /}
        {/node}
        {nodes href="chapter2\nodex.xml"}  {!-- make recursive, so that we can link in other files. 
                        should still load into same namespace. Or, multiple top-level. --}
      {/nodes}
    {/repository}
    

    Look at Alien Dice for partition model. I had a pretty good one, but I don't remeber the details.

    There is a bit of a difference between views that look at a single node (page view) and views that look over all the nodes (calendar view). How significant is this? I guess in some sense every view must be over the entire set of nodes, or how could the page view generate the navigation buttons? Perhaps all views are "centered" on a node but are allowed to traverse the entire data structure. A TOC view would basically ignore which node it was centered on. Interestingly, such a design allows for scoped TOCs, like showing all the pages of just the current chapter in thumbnail. (The hierarchical locator dropdown is also an example of a scoped TOC.)

    It looks like most controls could render with just a sequence id and a node id, plus some style information. In fact, the sequence id may not even be necessary - some controls may only work on certain sequences (calendar only works on by-date, etc.) Or, the sequence id is more of a "configure"-time parameter than a run-time parameter (hierarchical locator, prev/next buttons)

    C o m m e n t s :    
    (nothing yet)
    Edit