I was just going to suggest the Dublin Core metadata. We are already using it in DITA Learning, so perhaps some of that work can be leveraged? Thanks and best regards, --Scott Scott Hudson PELCO by Schneider Electric United States Standards & Information Architect Phone: +1 970 282 1952 Mobile: +1 720 369 2433 Email:
scott.hudson@schneider-electric.com Sites: pdn.pelco.com , partnerfirst.pelco.com On Nov 6, 2014, at 8:16 AM, Michael Priestley <
mpriestl@ca.ibm.com > wrote: Also looking at the standard metadata names here:
http://www.w3.org/TR/html5/document-metadata.html#standard-metadata-names And the registered extensions here
https://wiki.whatwg.org/wiki/MetaExtensions Especially the dc./dc ones. In map, we've just got navtitle and data - maybe add othermeta and be done with it? Otherwise we end up overprescribing metadata elements for the folks who don't need them. But we might want to specifically add metadata specialization to the allowed specialization axes. Michael Priestley, Senior Technical Staff Member (STSM) Enterprise Content Technology Strategist
mpriestl@ca.ibm.com http://dita.xml.org/blog/michael-priestley From: Don R. Day <
donday@donrday.com > To:
dita-lightweight-dita@lists.oasis-open.org Date: 11/06/2014 09:30 AM Subject: [dita-lightweight-dita] Example of blog-equivalent prolog metadata Sent by: <
dita-lightweight-dita@lists.oasis-open.org > 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 ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. ______________________________________________________________________