Not sure why you think so.  In the longer run I was thinking of
something like

<description>
 This is a great project, it does ...

 <markup type="html"><![CDATA[
   <h1>Great Project</h1>
   <p>This is a great project, it does ...
]]></markup>

 <markup type="docbook"><![CDATA[
   <sect1>
     <title>Great Project</title>
     <para>This is a great project, it does ...
   </sect1>
]]></markup>
</description>

and various frontends could ask the description element for the type
of description they can handle best ...  This would include stuff like
generating build documentations in various formats.

Yes! This is just what I was thinking. Sort of analogous to the HTML <img> tag which provides ALT
text if you can't handle images. Similarly, you could default to the plaintext <description>
unless you had a formatter that understood html or docbook markup.


But... one could provide this type of functionality regardless of whether <description>
was implemented as a subclass of DataType or Task, right? For that matter, Property could probably
be implemented as a DataType, too.


One way to think about this is to use responsibility driven design techniques. DataTypes can be
references, Tasks cannot. Tasks know who their "owning Target" is, DataTypes do not. Task itself does not enable references, but Property which inherits from Task, does.
DataTypes all inherit a capability to detect circular references. Because Properties can be defined
in terms of others in complex ways, the implementation couldn't be used directly, but...


I'm sure its something we could hash out in an hour around a large whiteboard :-) Alas, the limitations of
email..


--Craeg



Reply via email to