Mar 232011

LIF5BS:  (under construction; ~15% complete) 

  1. LIF5LC:  Intro

    1. LIF5R7:  This to be the leading repository for table definition & constructs used on
    2. LIF5ST:  It aims to include the following:
      1. LIF5TA:  Component definitions, including
        1. LIF5XT:  Columns
        2. LIF5V7:  CSS code
      2. LIF5TK:  Table definitions (which are chiefly collections of the above)
      3. LIF605:  It draws upon & (may become the future home of) my other leading table work including
        1. LIF62A:  term_etal_LF7LKL
        2. LIF6AE: =6AEKM37RH/_self_KY9VY8/history_KY9V40/L02F67.ods
        3. LIF7RW:  KM37RH/style_KMW0XW/template/table/_KZQ0N7.htm
    3. LIF5YP:  It is quite possible because of the extent of coverage this will need to be broken into sub-posts.
  2. LIF7T1:  Backend-Technology options (for tables)

    1. LIFEYM:  comparison table
      ID + Link(s) description                            
      LIF8W3:   col header1 use on use on synergy with data data code code code display display edit edit edit edit
      LIF801:    col header2 notable sites   expressiveness portability capabilities cleanliness portability in full in full in full in full snippet snippet
      LIF8UU:    col header3 2011.03.21   HTML           tools max size tools max size tools max size
      LIF80J: XHTML table-tag or similar CSS XHTML table-tag, or similar CSS heavy   identical high; dynamic nest-able types & somewhat extensible. medium for computation (revert to XML), high for viewing IF in the format one needs LIJB08:  minimal or 0     web browser 100s of rows, .4MB example MS Expression Web LIJAXT:  ~100 rows * ~15 columns none?  
      LIFF3E:   Google Docs Spreadsheet considering   "just" display live in iFrame     medium (JavaScript)     web browser   web browser      
      LIF82T:    spreadsheet as .odt only in background, as 6AE   export to XHTML but not well-supported     medium     OO Calc same as editing OO Calc LIJC03:  ~1000 rows of say 15 columns, as 6AE    
      LIF8D5: LIF8D5  XML DB as eXist or MarkLogic LIGUKH: =LIGUKH: starting to try to move to it, likely on "O'Reilly Media uses MarkLogic Server to power its ground-breaking SafariU custom publishing application." said 2007.04 (2,3); I also recall hearing Safari Books Online (as a whole) heard this by an XQuery presenter at a 2007.01 SoCalCodeCampp; other MarkLogic users & here. top (XHTML is  a subset); XRX is also notable, esp w/ GS[XSLTForms] and  XQIB (fr here) Among highest available. Fully dynamic, nest-able, & extensible types, all which most. Some troublesome arbitrariness as (store as an attribute value or a tag value). highest. The leading format high; [LIGRQJ:  GS[XML DB spatial] finds some as in eXist; MarkLogic offers.] [LIGRRV: pivoting appears ~as easy as could be, easier than SQL, so easy it's not worth mention; but GS[XForms pivot table] found none.] [LIGRS8: Cached- & lazy-computation of queries? GS[cached views XML] shows academic work on that; still probable given NN seems very high (using leader  XQuery). (nest-able?) ops take & return core powerful data-type (XML). seems high/ immediate     oXygen XML editors   XQuery, may interfaces [LIGRNN: =NNMarkLogic std up to 40GB & ~"100s TB via cloud"]
      [LIGROU: ~"110MB" as of "February 2006" .]
      LIFJGP:   additional DB in XML vs. SQL Since we can start fresh, seems best to start with XML DB, the better choice (perhaps given time) if support for it continues to grow.   Simulate XInclude & XQuery it in PHP suggests XML is #1 for inter-op, so useful to simulate it (as perhaps when one's not lucky enough to start w/ an XML DB?) Seemingly all SQL DBs output to XML for portability. XML much more expressive now & offers greater potential if properly supported.                    
      LIF83E:    SQL DB as MySQL (beyond WordPress,) considering strongly   not natural but well-supported medium: required structure powerful when it near-exactly fits but constraining when it doesn't or when partially fits. Typically requires programmer (formal schema edits) to extend (unless variable-field extensions used, which are possible but non-standard & not-well supported). Limited static types usually (unless say SQLite). Data NOT readily nest-able unless one builds nesting structures which then easily complicate code. Text, even XML, is not typically  parsed & indexed in any way by default except for full-text search, unless XML support added. Ops take & return tables mostly. medium-high (as structure is constraining) to (medium due to regular exceptions). Exceptions: a field is dynamically typed in SQLite, not in other SQL. highest (including OLAP ). [LIGRTT: Query from SQL shows XQuery seems somewhat more expressive but that doesn't get into high-end SQL.] seems medium to high seems requires translation in most cases, esp. given stored-procedure syntax & needed extensions are not standard   ?   ? SQL Update, many interfaces, incl. MySQL Workbench ~100GB here(search for MySQL) suggested by here

      LIF7TN:  As an example reading this table, from it one can see tables < ~100 rows * ~15 columns which require minimal or 0 calculations can be done as an XHTML table-tag or similar CSS.

  3. LIJB3V:  (JotHere table) to capture change (~10% complete)

    1. LIJB7O:  Introduction

      1. LIJB5C:  Systematically & completely capturing change/actions, for recording them (history) and (to a lesser degree) planning them, has been a profound interest of mine since ~1995.
      2.  LIJB82:  This section
        1. LIJBMH:  references & overviews & compares my work on the subject (past & present)
        2. LIJBHD:  presents some of my recent developments in this area, including
          1. LIJBHV:  serves as templating for such tables (what a use of a table can point to so the reader can know how to use & interpret it, plus defines for it a template & CSS code)
        3. LIJBK6:  holds further research on the topic.
        4. LIJBBA:  Has target areas of to document the changes (past & future)
          1. LIJBQ8:  of
            1. LIJBC6:  Any article/post/document, which I generalize as section (since sections can endlessly nested)
            2. LIJBD7:  IT system administration operations including maintenance to websites and a computers.
            3. LIJBES:  Versioning file-systems especially VCS
          2. LIJBQL:  as need by
            1. LIJBQW:  this site ( & its users
            2. LIJBR6:  but ideally it could be for anyone, too.
    2. LIBUFR:  action/change table (under construction)

        LIBUQB:   LIBXD8:  LIBUSV:   LIBVZB:   LIBWFZ:  LIBW56:  LIBVK2:     LIBZKO:          
      ID + Link(s) (link(s) situation just prior to start, giving enough detail to recreate) plan name description (including JavaScript, else English defining it using -ing verbs)

      Starting When:


      Ending When:

      (link(s) to) Further:

      Reasons including inspiration & preparation in effect:

      "was", "is", "will-be", or blank
      "Likelihood" (defaults to 100%)


  4. LIH4I5:  (table) Column definition table

    ID + Link(s) Parent(s) Definition Importance Column CSS  
    LI3922:  Li_Vert    Of ol & ul, sets the top & bottom margin to be 0 (instead of the default of 1)
    1. LI3DEP:  more often than not, I find this additional space wasteful & unhelpful, especially in a table cell but not just.
    2. LI3DGM:  This default setting 0 is used in WordPress and seemingly many other popular websites.
    3. LI3DRN:  this already is the default setting for ol & ul nested directly in another ol or ul.
    /*LI3D40: */ol,ul,.Li_Vert_LI3D40{/*

    1. LI3D8Y: */margin-top:0; margin-bottom:0;/*


    LI39G6: CSS statement(s)    A collection of CSS statements. In particular here I define a class CSS_statements_LI39IH which is used as follows:

    1. LI3A5Q:  applied to a div, the div serving as easy way to demarcate and select the CSS statements.
    2. LI3A70:  Iff the CSS is to be included inline, the div is proceeded by <style type="text/css">…</style> were the contents of that is set to be the ASCII-only contents of the div every time after the div contents have been edited.
    LI3ACC:  High, as it's used

    1. LI3ADG:  to define all the CSS used in this page
    2. LI3AEG:  ideally to define all the CSS on the site and ideally other sites.
    /*LI39IH: (div)*/.CSS_statements_LI39IH{/*

    1. LI3AV7: don't use say font-family:monospace; despite that's the convention for code as it wastes space (being monospace) and is not as pretty, and I want code to look prettier especially when now it's included along with HTML and can include full HTML, plus this encourages writing more comments.
    2. LI39VK: */background:aqua;/* -might be too highlighting & intense, but works for now.


    LI3GIN: named UID link    A named link (a-tag) to a universal ID anchor; example: "named UID link" LI3GLY:  Highest as it's used all references here. 

    1. LI3HIT:  As with any HTML link, it's good to create a nicely named link at the destination in advance: then to create a nicely named reference to the destination, one just copy that nicely named link.
    2. LI3HTY: Also because the anchor is a global unique ID, generally many good things are possible.

    LI3HI3:  In short I find this essential, key, & indispensible.

    LI3EMK: ID + Link(s)    In a table, contains the universal ID for the row plus any named UID links to it/here (each also giving a name to it) each separated by a space. If the first row of column headings also contains this kind of value, this also applies to them, too, even though/if it's not listed to the left/right of them. LI3G9C:  High as it's used for all tables, to name the rows & reference the rows & columns

    1. LI3GAR:  For each table, for every data row, and optionally for every column (including the ID + Link(s) itself), it allows a globally unique (universal ID) be given, along with a link to it plus name(s) to it.
    2. LI3HVO:  all the advantages from using a named UID link
    3. LI3IFQ:  See The only row or column without IDs are the header rows
    /*LI3EYT: (col)*/.ID_n_Links_LI3EYT{/*

    1. LI3F0N: */width:4em;/*


    LI3LKQ: Parent(s)  categories   named UID link(s), separated by space, to immediate parent concept(s). Think parent section in an outline. LI3LOC:  High. Used a lot here. See compared to an outline.
    /*LI3MSH: (col)*/.Parents_LI3MSH{/*

    1. LI3MUJ: */width:3em;/*


    LI3KE0: Definition    Definition. This was also " & Description" so some cells may still have description text as well.  
    /*LI3KKP: (col)*/.Definition_LI3KKP{/*

    1. LI3KM8: */width:18em;/*


    LI1JBB: Importance   Importance. Note this could include usage if that's what establishes the importance, as usage often does.  
    /*LI38M6: (col)*/.Importance_LI1JBB{/*

    1. LI38RI: */width:20em;/*


    LI36Z9:  Column CSS    CSS statement(s) to define the column

    1. LI39CZ:  Use this entry's value for Column CSS as a starter template for other table values.
    2. LI398U:  Uses CSS statements
    3. LI3B8B:  The name of each CSS class defined:
      1. LI3BNM:  Begins with the name of the overall-concept/row (with punctuation removed & whitespace replaced with "_") for easy human understanding & lookup.
      2. LI3BCQ:  ends with "_" followed by the universal ID of the first statement which defines it, NOT the universal ID of the row/overall-concept being defined, as Reasons U4.
    LI37QL:  Medium

    1. LI37R5:  every column needs to be defined fixed-width for scalable performance: for, at least in MS Expression Web 4 (and possibly in other WYSIWYG editors), at least without this, every keystroke inserted in the document wrongfully gets increasingly slow (to the point of impractical), even when not entering into a table, probably because the editor is wrongfully immediately re-computing what the column widths should be (and of all tables, even when not even changing a table).
    2. LI3842:  It would be nice to color-code columns.
    /*LI37EI: (col)*/.Column_CSS_LI36Z9{/*

    1. LI37GE: */width:12em;/*


  5. LIGVAZ:  Section Change Table (in order)

    ID + Link(s) (Starting setting/environment), else attribute How modifying When:

    Starting Reason including inspiration & preparation Results Ender:

    LIH4KM:   relevant dimension attribute table added column definitions, including:
    [LIH4RY: RY many (as Li_Vert & ID + Link(s)) which would apply fairly universally]
    LIF5M0:    title exists not. set to " table"
    To gather table constructs for JotHere. done immediately
    LIF4TE:  TE post exists not. set to
    usual done immediately
          now usual    
    LIF505:   draft source exists not. set to 368[JotHere.com_table]_LIF505.htm
    usual done immediately
    LIGTJR:   draft source's Intro added.
    finished yesterday
    LIGTPJ: draft source's section Backend-Technology options (for tables) added
    in progress; ~80%
    usual done immediately
    LIGU0H:  0H TE save draft
    ending 22 March, 2011 @ 1:27
    good recordkeeping: going to sleep  
    LIH4EC: LIH4EC   to draft source's Column definition table from all-of RY. create, moving content
    a few days ago
    now; in progress.
    Need these to be in a more central location as they are universal moved; need to update links
    LIJCOY:   top-level section (JotHere table) to capture change created and added intro. Included action/change table (which was elsewhere). That & rest still under construction
    ended now.
    per the docs' directive. done
    LIGTSV:  SV 0H publish draft
    ; LIJG54:  posting:
    Want to put "I now work full-time with WordPress (MySQL plus its own PHP framework) and we're starting a move to XML DB (XQuery) per ,but it's good to keep abreast w/ other technologies as this and hang with fellow techies." on  LIF8D5 reference in comment on done immediately
      source's content (template row; copy & paste it then edit to suit)
    usual done immediately
  6. Copyright © 2011 by with all rights reserved.

Section table end

  One Response to “ table”

  1. […] w/ WordPress (its own PHP framework w/ MySQL) &we're starting a move2 XML DB (XQuery) per ,but it's good to keep abreast w/ other technologies as this & hang w/ fellow techies […]