Example of "blog-equivalent prolog metadata"

By the way, I've been using the following full-DITA structure to
    hold the kind of data that is normally/minimally used to track blog
    publishing. Some of these fields are obviously useful for general
    content tracking as well (wiki pages may use much of this other than
    "feature image", for example).

    

        <prolog>

            <author type="creator">Michael
    Priestley</author><!-- Consider
      whether the "creator" semantic merits a single name/value
      othermeta slug instead. -->

            <critdates>

                <created  date="2014-07-12"/><!--
      Note that golive and expiry are needful as well; I'd get by if
      these were all in othermeta slugs. -->

            </critdates>

            <metadata>

                <category>documentation</category>

                <othermeta name="featureImage"
    content="generic.png"/><!-- This is the
      image commonly associated with blurbs, carousels, banners, etc.
      wherever the post is referenced. It is not simply an image in the
      content because it needs to be regularly identified as a feature
      image (and the name itself may be a key for thumbnails and
      alternate sizes in the db)..-->

                <othermeta name="status" content="draft"/><!-- The content atttype may use any tokens
      that a local organization prefers, rather than trying to attach
      publishing workflows on DITA's topic/@status, (which is not even
      with the rest of the prolog; I think that is a potential 2.0
      reconsideration). -->

            </metadata>

        </prolog>

    

    The HDITA equivalent could be simply a sequence of meta name/value
    elements, which begs the question of why DITA had structured
    metadata in the first place. That question belongs to the DITA 2.0
    scope of discussion--we are stuck, I think, with using what we have,
    although we could use othermeta in the same way to simply replicate
    the author and date fields as part of a simple sequence. It would
    still need to be nested twice for no apparent reason, but that's
    invisible to the author if the XDITA editor uses a form for the
    metadata inputs anyway.

    

    Maps won't need quite the same data; I think that only dates and
    status may apply since maps are more ephemeral in a direct-display
    workflow. (Search results, bookmarks, subset print lists, posts by
    month or campaign, etc. are all throw-away lists with little
    provenance, for example.)

    

    The main nature of this metadata is direct publishing workflow; this
    is different from standard DITA where the usual role for metadata is
    source management (with some publishing slipped in). This may
    require some thinking and discussion.  One way to think of the
    difference is to contrast the two-database workflows of techpubs
    (manage source/build concerns on one, publishing concerns on another
    outside the firewall) with cases where both source control and
    publishing are from a single database (like blogs or wikis) and the
    DITA is consumed directly by the web application, whether that be
    "render-in-browser" like Chris Depopulous's reader), "transformed on
    the server" (a la expeDITA model), or "served via API" to an app for
    data-munging or content republishing with local (non-browser)
    services.

    

    For now, the main question is what other metadata might need to be
    considered for other use cases outside the usual techpub model.
    We'll come across those as we step through the scenarios. Hmm, do we
    need a callout for specific new metadata considerations in the
    templates?

    
-- 

      
      
        
Don R. Day

        
Co-Founder, ContelligenceGroup.com

        
Founding Chair, OASIS
            DITA Technical Committee

        
LinkedIn: donrday   Twitter:
          @donrday

        
About.me: Don R. Day   Skype:
          don.r.day

      
      
        
"Where is the wisdom we have lost in knowledge?

        
Where is the knowledge we have lost in information?"

        
--T.S. Eliot