Comments on: Content microarchitecture: How I learned to love HTML part 2 http://blog.technologyofcontent.com/2009/11/content-microarchitecture-how-i-learned-to-love-html-part-2/ Ramblings on the technology of content management Tue, 30 Aug 2011 15:38:33 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: paradox1x http://blog.technologyofcontent.com/2009/11/content-microarchitecture-how-i-learned-to-love-html-part-2/comment-page-1/#comment-3556 paradox1x Mon, 18 Jan 2010 20:58:07 +0000 http://blog.technologyofcontent.com/?p=145#comment-3556 <p><strong>More from Daniel Jacobson on NPR's content management ecosystem...</strong></p> <p>Programmable Web: Daniel Jacobson: "Content Portability: Building an API is Not Enough" Previous entries in the series: Programmable Web: Daniel......</p> More from Daniel Jacobson on NPR’s content management ecosystem…

Programmable Web: Daniel Jacobson: “Content Portability: Building an API is Not Enough” Previous entries in the series: Programmable Web: Daniel……

]]> By: Sorry, it’s too late to COPE « CMSish http://blog.technologyofcontent.com/2009/11/content-microarchitecture-how-i-learned-to-love-html-part-2/comment-page-1/#comment-2626 Sorry, it’s too late to COPE « CMSish Fri, 04 Dec 2009 13:22:17 +0000 http://blog.technologyofcontent.com/?p=145#comment-2626 <p>[...] on the content storage strategy they’ve adopted for the U.S National Public Radio (via Justin Cormack). The basic  idea is to ensure hardcore content portability by very cleanly splitting out [...]</p> [...] on the content storage strategy they’ve adopted for the U.S National Public Radio (via Justin Cormack). The basic  idea is to ensure hardcore content portability by very cleanly splitting out [...]

]]> By: Daniel Jacobson http://blog.technologyofcontent.com/2009/11/content-microarchitecture-how-i-learned-to-love-html-part-2/comment-page-1/#comment-2425 Daniel Jacobson Tue, 24 Nov 2009 21:22:44 +0000 http://blog.technologyofcontent.com/?p=145#comment-2425 <p>Justin, Nice breakout on the five points of handling markup in text. NPR's philosophy of COPE (coupled with our strategy for distribution) suggests that we should be storing our markup in a normalized way. But as you point out in your fourth point, this decision may not be appropriate for other systems. Making that decision requires a sound review of the business goals as well as an assessment of the technical architecture. In some cases, implementing a normalized markup model will be very difficult and, if the distribution strategy is limited, that extra work would not realize dividends.</p> <p>As you emphasized, the decision to go one way or the other should be a calculated one. My article hopefully demonstrates that there are other approaches and opportunities other than (what seems to be) the default approach of adding plug-ins that strip out the markup on distribution rather than storage.</p> Justin, Nice breakout on the five points of handling markup in text. NPR’s philosophy of COPE (coupled with our strategy for distribution) suggests that we should be storing our markup in a normalized way. But as you point out in your fourth point, this decision may not be appropriate for other systems. Making that decision requires a sound review of the business goals as well as an assessment of the technical architecture. In some cases, implementing a normalized markup model will be very difficult and, if the distribution strategy is limited, that extra work would not realize dividends.

As you emphasized, the decision to go one way or the other should be a calculated one. My article hopefully demonstrates that there are other approaches and opportunities other than (what seems to be) the default approach of adding plug-ins that strip out the markup on distribution rather than storage.

]]>