<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments for Greyfiti</title>
	<atom:link href="http://greyfiti.com/comments/feed/" rel="self" type="application/rss+xml" />
	<link>http://greyfiti.com</link>
	<description>life as a tech writer on the cusp of the diamond age</description>
	<lastBuildDate>Sat, 04 Sep 2010 13:30:41 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>Comment on A new minimalist principle that John M. Carroll didn&#8217;t think of &#8211; Increase acquisition speed by Shannon Greywalker</title>
		<link>http://greyfiti.com/2010/a-new-minimalist-principle-that-john-m-carroll-didnt-think-of-increase-acquisition-speed/comment-page-1/#comment-514</link>
		<dc:creator>Shannon Greywalker</dc:creator>
		<pubDate>Sat, 04 Sep 2010 13:30:41 +0000</pubDate>
		<guid isPermaLink="false">http://greyfiti.com/?p=192#comment-514</guid>
		<description>I apologize for the delay, I originally thought that I&#039;d have time in the first few sprints of a new release to finish it up, but quite a few high-priority stories arose that have been consuming my time. At this point it&#039;s looking like another 4 to 6 weeks.</description>
		<content:encoded><![CDATA[<p>I apologize for the delay, I originally thought that I&#8217;d have time in the first few sprints of a new release to finish it up, but quite a few high-priority stories arose that have been consuming my time. At this point it&#8217;s looking like another 4 to 6 weeks.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on A new minimalist principle that John M. Carroll didn&#8217;t think of &#8211; Increase acquisition speed by Mick</title>
		<link>http://greyfiti.com/2010/a-new-minimalist-principle-that-john-m-carroll-didnt-think-of-increase-acquisition-speed/comment-page-1/#comment-513</link>
		<dc:creator>Mick</dc:creator>
		<pubDate>Thu, 02 Sep 2010 20:03:49 +0000</pubDate>
		<guid isPermaLink="false">http://greyfiti.com/?p=192#comment-513</guid>
		<description>Very much looking forward to seeing the guide to your methodology. Any update on when it will be available? Thanks.</description>
		<content:encoded><![CDATA[<p>Very much looking forward to seeing the guide to your methodology. Any update on when it will be available? Thanks.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Why minimalist documentation is not always a good match for agile development by Shannon Greywalker</title>
		<link>http://greyfiti.com/2009/why-minimalist-documentation-not-always-good-match-for-agile-development/comment-page-1/#comment-470</link>
		<dc:creator>Shannon Greywalker</dc:creator>
		<pubDate>Thu, 06 May 2010 16:58:23 +0000</pubDate>
		<guid isPermaLink="false">http://greyfiti.com/?p=114#comment-470</guid>
		<description>It&#039;s a bit premature to roll out but since this comment is buried in an older post&#039;s comment thread, it&#039;s probably safe to give a sneak peek here. I&#039;ve spent the past 6 months working on a complete methodology for authoring minimalist documentation. There are still a few &quot;to be written&quot; holes that I&#039;ve yet to complete, but the guide is 98% baked and stable at this point.

Of special interest to you might be the topic &quot;Task: Authoring minimalist topics in an agile environment&quot;.

Enjoy!:  http://greyfiti.wikidot.com/sdg:gmeth-start-minimalism-greywalker-method</description>
		<content:encoded><![CDATA[<p>It&#8217;s a bit premature to roll out but since this comment is buried in an older post&#8217;s comment thread, it&#8217;s probably safe to give a sneak peek here. I&#8217;ve spent the past 6 months working on a complete methodology for authoring minimalist documentation. There are still a few &#8220;to be written&#8221; holes that I&#8217;ve yet to complete, but the guide is 98% baked and stable at this point.</p>
<p>Of special interest to you might be the topic &#8220;Task: Authoring minimalist topics in an agile environment&#8221;.</p>
<p>Enjoy!:  <a href="http://greyfiti.wikidot.com/sdg:gmeth-start-minimalism-greywalker-method" rel="nofollow">http://greyfiti.wikidot.com/sdg:gmeth-start-minimalism-greywalker-method</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Why minimalist documentation is not always a good match for agile development by Shannon Greywalker</title>
		<link>http://greyfiti.com/2009/why-minimalist-documentation-not-always-good-match-for-agile-development/comment-page-1/#comment-469</link>
		<dc:creator>Shannon Greywalker</dc:creator>
		<pubDate>Thu, 06 May 2010 16:54:59 +0000</pubDate>
		<guid isPermaLink="false">http://greyfiti.com/?p=114#comment-469</guid>
		<description>XML (and its precursor SGML) have a lot of technical jargon and concepts that are unique. There isn&#039;t any simple &quot;get a leg up&quot; approach to learning the jargon and terminology other than wading in. The Wikipedia article on XML (http://en.wikipedia.org/wiki/Xml) can point you in the right direction for learning the basic concepts, especially if you explore the &quot;External Links&quot; section at the bottom.

DITA is a particular implementation of XML that: A) provides a simple set of document types (task, concept, reference) that are all specialized from a single generic document type called &quot;topic&quot;. What makes DITA unique is that you can create new specializations of your own from any of these four base document types. And if you hand one of your specialized document types to another company that uses DITA but not your particular specialized document type, the DITA environment will automatically generalize your document upwards to one of the four base document types.

In plain English, this means that if you create a custom version of a &quot;task&quot; topic, for example, that contains some new custom tags you want to use in your company&#039;s DITA/XML environment, when you hand that document to some other company, your new custom tags will be converted back to the original tag in the base &quot;task&quot; document type from which you originally specialized your custom tags. This surmounts a major hurdle with XML adoption, which is the simple fact that every company tweaks some published document type standard such as DocBook or DITA to their own liking, and once you&#039;ve made such customizations, your XML files can no longer be used by anyone else without a lot of expensive transformation scripts being designed to convert your document types to their document types.  DITA essentially automates all this transformation stuff for you.

So that&#039;s DITA in a nutshell but again, there are many special concepts and jargons associated with DITA that you must layer on top of the basic concepts and jargon of XML. Again, your best bet is to start with the Wikipedia article on DITA (http://en.wikipedia.org/wiki/Darwin_Information_Typing_Architecture), and you might find it fruitful to explore some of the &quot;external links&quot; at the bottom.</description>
		<content:encoded><![CDATA[<p>XML (and its precursor SGML) have a lot of technical jargon and concepts that are unique. There isn&#8217;t any simple &#8220;get a leg up&#8221; approach to learning the jargon and terminology other than wading in. The Wikipedia article on XML (<a href="http://en.wikipedia.org/wiki/Xml" rel="nofollow">http://en.wikipedia.org/wiki/Xml</a>) can point you in the right direction for learning the basic concepts, especially if you explore the &#8220;External Links&#8221; section at the bottom.</p>
<p>DITA is a particular implementation of XML that: A) provides a simple set of document types (task, concept, reference) that are all specialized from a single generic document type called &#8220;topic&#8221;. What makes DITA unique is that you can create new specializations of your own from any of these four base document types. And if you hand one of your specialized document types to another company that uses DITA but not your particular specialized document type, the DITA environment will automatically generalize your document upwards to one of the four base document types.</p>
<p>In plain English, this means that if you create a custom version of a &#8220;task&#8221; topic, for example, that contains some new custom tags you want to use in your company&#8217;s DITA/XML environment, when you hand that document to some other company, your new custom tags will be converted back to the original tag in the base &#8220;task&#8221; document type from which you originally specialized your custom tags. This surmounts a major hurdle with XML adoption, which is the simple fact that every company tweaks some published document type standard such as DocBook or DITA to their own liking, and once you&#8217;ve made such customizations, your XML files can no longer be used by anyone else without a lot of expensive transformation scripts being designed to convert your document types to their document types.  DITA essentially automates all this transformation stuff for you.</p>
<p>So that&#8217;s DITA in a nutshell but again, there are many special concepts and jargons associated with DITA that you must layer on top of the basic concepts and jargon of XML. Again, your best bet is to start with the Wikipedia article on DITA (<a href="http://en.wikipedia.org/wiki/Darwin_Information_Typing_Architecture" rel="nofollow">http://en.wikipedia.org/wiki/Darwin_Information_Typing_Architecture</a>), and you might find it fruitful to explore some of the &#8220;external links&#8221; at the bottom.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Why minimalist documentation is not always a good match for agile development by Kay</title>
		<link>http://greyfiti.com/2009/why-minimalist-documentation-not-always-good-match-for-agile-development/comment-page-1/#comment-468</link>
		<dc:creator>Kay</dc:creator>
		<pubDate>Thu, 06 May 2010 14:25:23 +0000</pubDate>
		<guid isPermaLink="false">http://greyfiti.com/?p=114#comment-468</guid>
		<description>As an additional comment, though, your article explains exactly what I have been trying to tell my boss, that when working in Agile, I feel like I&#039;m trying to describe the elephant when I only can see part of its tail!</description>
		<content:encoded><![CDATA[<p>As an additional comment, though, your article explains exactly what I have been trying to tell my boss, that when working in Agile, I feel like I&#8217;m trying to describe the elephant when I only can see part of its tail!</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Why minimalist documentation is not always a good match for agile development by Kay</title>
		<link>http://greyfiti.com/2009/why-minimalist-documentation-not-always-good-match-for-agile-development/comment-page-1/#comment-467</link>
		<dc:creator>Kay</dc:creator>
		<pubDate>Thu, 06 May 2010 14:16:17 +0000</pubDate>
		<guid isPermaLink="false">http://greyfiti.com/?p=114#comment-467</guid>
		<description>Hi, Shannon,

I am enjoying this article, but it brings me to a side point. I have been trying to grasp the concept of DITA for years. I don&#039;t consider myself to be stupid by any means, but one of the problems I have with understanding the purpose and use of DITA is sentences like this fragment from your article. &quot;Some ingenious and unique techniques for specializing a generalized XML content model into new content models in a way that enables output processing to back-level its processing code to the style and transform rules of the generalized ancestors, if necessary, without “breaking” the output processing.&quot; What does this mean? Am I being dense? In particular, what does &quot;back-level its processing code to the style and transform rules of the generalized ancestors,&quot; mean? Whenever I try to understand DITA I see sentences like this. Really, I&#039;m not criticizing your writing, but is there somewhere I can read more basic information that doesn&#039;t assume that level of vocabulary?</description>
		<content:encoded><![CDATA[<p>Hi, Shannon,</p>
<p>I am enjoying this article, but it brings me to a side point. I have been trying to grasp the concept of DITA for years. I don&#8217;t consider myself to be stupid by any means, but one of the problems I have with understanding the purpose and use of DITA is sentences like this fragment from your article. &#8220;Some ingenious and unique techniques for specializing a generalized XML content model into new content models in a way that enables output processing to back-level its processing code to the style and transform rules of the generalized ancestors, if necessary, without “breaking” the output processing.&#8221; What does this mean? Am I being dense? In particular, what does &#8220;back-level its processing code to the style and transform rules of the generalized ancestors,&#8221; mean? Whenever I try to understand DITA I see sentences like this. Really, I&#8217;m not criticizing your writing, but is there somewhere I can read more basic information that doesn&#8217;t assume that level of vocabulary?</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Concrete strategies for using minimalism in an agile development environment by Agile &#38; Tech Comm: Can This Union Work? &#171; Write Trends</title>
		<link>http://greyfiti.com/2010/strategies-using-minimalism-agile-development-environment/comment-page-1/#comment-466</link>
		<dc:creator>Agile &#38; Tech Comm: Can This Union Work? &#171; Write Trends</dc:creator>
		<pubDate>Wed, 14 Apr 2010 01:13:06 +0000</pubDate>
		<guid isPermaLink="false">http://greyfiti.com/?p=139#comment-466</guid>
		<description>[...] http://greyfiti.com/2010/strategies-using-minimalism-agile-development-environment [...]</description>
		<content:encoded><![CDATA[<p>[...] <a href="http://greyfiti.com/2010/strategies-using-minimalism-agile-development-environment" rel="nofollow">http://greyfiti.com/2010/strategies-using-minimalism-agile-development-environment</a> [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Why minimalist documentation is not always a good match for agile development by Arun</title>
		<link>http://greyfiti.com/2009/why-minimalist-documentation-not-always-good-match-for-agile-development/comment-page-1/#comment-465</link>
		<dc:creator>Arun</dc:creator>
		<pubDate>Tue, 13 Apr 2010 10:03:21 +0000</pubDate>
		<guid isPermaLink="false">http://greyfiti.com/?p=114#comment-465</guid>
		<description>Very good article with great clarity of the minimalist documentation.

I hope to get more updates from your side and thanks for this fabulous work.</description>
		<content:encoded><![CDATA[<p>Very good article with great clarity of the minimalist documentation.</p>
<p>I hope to get more updates from your side and thanks for this fabulous work.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Evolutionary documentation by Greyfiti &#187; Blog Archive &#187; Why minimalist documentation is not always a good match for agile development</title>
		<link>http://greyfiti.com/2009/evolutionary-documentation/comment-page-1/#comment-165</link>
		<dc:creator>Greyfiti &#187; Blog Archive &#187; Why minimalist documentation is not always a good match for agile development</dc:creator>
		<pubDate>Fri, 12 Feb 2010 19:51:52 +0000</pubDate>
		<guid isPermaLink="false">http://greyfiti.com/?p=87#comment-165</guid>
		<description>[...] I&#8217;ve detailed in my Evolutionary Documentation post on this blog, agile development forces your user documentation to grow and evolve alongside [...]</description>
		<content:encoded><![CDATA[<p>[...] I&#8217;ve detailed in my Evolutionary Documentation post on this blog, agile development forces your user documentation to grow and evolve alongside [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Why minimalist documentation is not always a good match for agile development by Greyfiti &#187; Blog Archive &#187; Concrete strategies for using minimalism in an agile development environment</title>
		<link>http://greyfiti.com/2009/why-minimalist-documentation-not-always-good-match-for-agile-development/comment-page-1/#comment-110</link>
		<dc:creator>Greyfiti &#187; Blog Archive &#187; Concrete strategies for using minimalism in an agile development environment</dc:creator>
		<pubDate>Sun, 10 Jan 2010 16:40:45 +0000</pubDate>
		<guid isPermaLink="false">http://greyfiti.com/?p=114#comment-110</guid>
		<description>[...] my post from last month about Why minimalist documentation is not always a good match for agile development, I explained the issues with using minimalism in an agile environment but was unable to offer any [...]</description>
		<content:encoded><![CDATA[<p>[...] my post from last month about Why minimalist documentation is not always a good match for agile development, I explained the issues with using minimalism in an agile environment but was unable to offer any [...]</p>
]]></content:encoded>
	</item>
</channel>
</rss>
