.\" 
.\" monodocer manual page.
.\" (C) 2006 Jonathan Pryor
.\" Author:
.\"   Jonathan Pryor (jonpryor@vt.edu)
.\"
.de Sp \" Vertical space (when we can't use .PP)
.if t .sp .5v
.if n .sp
..
.TH "monodocer" 1
.SH "نام (NAME)"
monodocer \- پشتیبانی از قالب مستندسازی ECMA
.SH "خلاصه دستور (SYNOPSIS)"
.B monodocer
[OPTIONS]*
.SH "گزینه‌ها (OPTIONS)"
.TP
.I \-assembly:ASSEMBLY
.I ASSEMBLY
یک اسمبلی دات‌نت (.NET) است که چارچوب‌های مستندسازی (stubs) برای آن ایجاد می‌شود.
.Sp
یک مسیر فایل یا نام یک اسمبلی ثبت‌شده در GAC را مشخص کنید.
.TP
.I \-delete
اجازه دادن به monodocer برای حذف اعضا از فایل‌های مستندات.
تنها اعضایی حذف می‌شوند که دیگر در درون اسمبلی حضور ندارند.
.Sp
اگر یک نوع (type) دیگر وجود نداشته باشد، فایل مستندات
.I حذف نمی‌شود\fR،
بلکه در عوض با پسوند
.B .remove
.I تغییر نام می‌یابد\fR.
.TP
.I \-?, \-help
نمایش اطلاعات آرگومان‌های برنامه.
.TP
.I \-ignoremembers
اعضا به‌روزرسانی نشوند.
.Sp
این گزینه چارچوب‌های مستندسازی را برای نوع‌های اضافه‌شده درج می‌کند، اما مستندات هیچ‌یک از اعضای هیچ نوعی را (شامل نوع‌های جدیداً اضافه‌شده)
.I اضافه یا حذف نخواهد کرد\fR.
.TP
.I \-importslashdoc:FILE
.I FILE
یک فایل XML است که توسط پرچم
.B /doc:FILE
در کامپایلر C# تولید شده است (برای مثال
.I mcs -doc:foo.xml foo.cs
). مستندات اعضای موجود در
.I FILE
را به قالب مستندسازی مورداستفاده توسط monodoc وارد (import) می‌کند.
.TP
.I \-name:NAME
.I NAME
نام پروژه‌ای است که این مستندات متعلق به آن است.
.Sp
این گزینه عنصر
.I /Overview/Title
را درون فایل
.I index.xml
که در دایرکتوری مشخص‌شده توسط
.I -path
ایجاد می‌شود، تنظیم می‌کند.
این مقدار توسط برخی برنامه‌ها برای اطلاعات عنوان (مانند
.I monodocs2html
) استفاده می‌شود.
.TP
.I \-namespace:NAMESPACE
تنها نوع‌های موجود در فضای نام (namespace)
.I NAMESPACE
به‌روزرسانی شوند.
.TP
.I \-overrides
گنجاندن متدهای بازنویسی‌شده (overridden) در مستندات.
.Sp
این کار معمولاً ضروری نیست، زیرا مرورگر مستندات مونو (Mono Documentation Browser) در هر صورت پیوندی به اعضای نوع پایه (base type) فراهم می‌کند؛ همچنین اگر نوع پایه درون همان اسمبلی باشد،
.I monodocs2html
نیز این پیوند را ایجاد خواهد کرد.
.TP
.I \-path:OUTPUT_DIR
.I OUTPUT_DIR
دایرکتوری است که چارچوب‌های مستندسازی جدید/به‌روزشده را در بر خواهد داشت.
.TP
.I \-pretty
دندانه‌گذاری و قالب‌بندی مرتب فایل‌های XML.
.TP
.I \-since:SINCE
ایجاد یک عنصر <since/> برای نوع‌ها و اعضای اضافه‌شده با مقدار
.I SINCE
\&.
.Sp
برای مثال، در صورت استفاده از
.I -since:"Gtk# 2.4"
عنصری در عنصر
.I Docs
برای تمام نوع‌ها و اعضای نوعِ اضافه‌شده درج خواهد شد:
.nf
	<since version="Gtk# 2.4" />
.fi
مرورگر مستندات مونو (Mono Documentation Browser) و
.I monodocs2html
از این عنصر برای مشخص کردن این که یک عضو در کدام نسخه اضافه شده است استفاده خواهند کرد.
.TP
.I \-type:TYPE
تنها ایجاد/به‌روزرسانی مستندات برای نوعِ
.I TYPE
\&.
.TP
.I \-updateto:PATH
هنگام به‌روزرسانی مستندات، نوشتن فایل‌های مستندات به‌روزشده در دایرکتوری
.I PATH
\&.
.TP
.I \-V, \-version
نمایش نسخه و اطلاعات مجوز (لایسنس).
.PP.SH "توضیحات (DESCRIPTION)"
برنامه \fBmonodocer\fR منسوخ شده و با \fBmdoc\fR(1) جایگزین شده است. به صفحه
راهنمای \fBmdoc-update\fR(1) مراجعه کنید.
.PP
.I monodocer
برنامه‌ای است که اسکلت‌های اولیه (stubs) مستندات XML را در قالب مستندات ECMA
ایجاد می‌کند. این ابزار به مستندات موجود در کد منبع متکی نیست.
.PP
مزایای آن عبارتند از:
.TP
.I *
.B خوانایی کد.
مستندات خوب معمولاً (الف) مفصل بوده و (ب) پر از مثال است. (برای مقایسه، مستندات
Microsoft .NET Framework را که اغلب شامل یک صفحه یا بیشتر برای هر عضو است، با
مستندات JavaDoc که غالباً در حد یک جمله برای هر عضو است مقایسه کنید.)
.Sp
قرار دادن مستندات خوب درون کد منبع معمولاً حجم فایل منبع را به‌شدت افزایش می‌دهد،
چرا که حجم مستندات می‌تواند از متدِ واقعی در حال مستندسازی بسیار طولانی‌تر باشد.
.TP
.I *
.B بومی‌سازی.
قالب‌های مستندسازی درون‌کدی (مانند 
.B /doc
) هیچ پشتیبانی‌ای از چندین زبان انسانی ندارند. اگر برای اهداف مستندسازی نیاز به
پشتیبانی از بیش از یک زبان انسانی دارید، 
.I monodocer
بسیار سودمند است چرا که اجازه می‌دهد هر زبان دایرکتوری اختصاصی خود را داشته باشد، و 
.I monodocer
می‌تواند نوع‌ها/عضوها را برای هر دایرکتوری مستندات به‌صورت جداگانه اضافه کند.
.TP
.I *
.B مدیریت.
وجود تیم‌های مجزای مستندسازی و توسعه امر غیرمعمولی نیست. همچنین ممکن است تیم
مستندسازی تجربه ناچیزی در زبان برنامه‌نویسی مورد استفاده داشته باشد. در چنین
شرایطی، مستندسازی درون‌خطی مطلوب نیست زیرا ممکن است تیم مستندسازی هنگام
به‌روزرسانی مستندات، سهواً خطایی وارد کد منبع کند. علاوه بر این، ممکن است به دلایل
امنیتی نخواهید تیم مستندسازی به کد منبع دسترسی داشته باشد.
.I monodocer
امکان نگهداری مستندات را به‌صورت 
.I کاملاً
جدا و متمایز از کد منبع مورد استفاده برای ساخت اسمبلی فراهم می‌کند.
.PP
برای تبدیل مستندات 
.I monodocer 
به قالبی که توسط Mono Documentation Browser (مرورگر راهنمای رومیزی یا رابط وب آن)
قابل استفاده باشد، کامپایل مستندات به یک قالب بسته‌بندی‌شده (packed) ضروری است.
این کار با ابزار mdassembler انجام می‌شود؛ برای مثال، می‌توانید از این زنجیره ابزار
به این صورت استفاده کنید:
.nf

	$ monodocer -assembly:MyWidgets -path:generated_docs
	$ mdassembler --ecma generated_docs -out:MyWidgets

.fi
دستورات بالا دو فایل MyWidgets.zip و MyWidgets.tree تولید می‌کنند که سپس می‌توان
آن‌ها را در سیستم نصب کرد. علاوه بر این دو فایل (.zip و .tree)، باید یک فایل .sources
نیز فراهم کنید که مشخص می‌کند مستندات باید در کجای سامانه راهنما پیوند داده شوند؛
این یک فایل XML بسیار ساده است، مانند زیر:
.nf

<?xml version="1.0"?>
<monodoc>
  <source provider="ecma" basefile="MyWidgets" path="classlib-gnome"/>
</monodoc>

.fi
فایل پیکربندی بالا بیان می‌کند که مستندات در قالب ECMA (نسخه کامپایل‌شده) قرار دارند،
نام پایه فایل MyWidgets است و باید در بخش "classlib-gnome" از درخت متصل شوند.
اگر می‌خواهید گره‌های مختلف تعریف‌شده در مستندات را بررسی کنید، می‌توانید به فایل
monodoc.xml نگاه کنید که معمولاً در مسیر /usr/lib/monodoc/monodoc.xml نصب می‌شود.
.PP
هنگامی که همه فایل‌های خود (.zip، .tree و .sources) را آماده کردید، می‌توانید با دستور
زیر آن‌ها را در سیستم نصب کنید:
.nf

        $ cp MyWidgets.tree MyWidgets.zip MyWidgets.source `pkg-config monodoc --variable sourcesdir`
  
.fi
دستور بالا فایل‌ها را در دایرکتوری‌ای که Monodoc ثبت کرده است کپی می‌کند (برای انجام
این کار ممکن است به دسترسی‌های ریشه/مدیر سیستم (root) نیاز داشته باشید). دایرکتوری
واقعی با اجرای 
.I pkg-config 
بازگردانده می‌شود..SH "قالب شناسه رشته‌ای (STRING ID FORMAT)"
شناسه‌های رشته‌ای (String IDs) برای اشاره به یک نوع یا عضوی از یک نوع به کار می‌روند. شناسه‌های رشته‌ای در
ECMA-334 ویرایش سوم، ضمیمه E.3.1 مستند شده‌اند. آن‌ها از یک
.I پیشوند نوع عضو
، نام کامل نوع (فضای نام + نام، جدا شده با «.»)، و احتمالاً در ادامه نام عضو و اطلاعات دیگر تشکیل شده‌اند.
.PP
پیشوندهای نوع عضو:
.TP
.I "E:"
شناسه رشته‌ای به یک رویداد (event) اشاره دارد. نام رویداد پس از نام نوع می‌آید:
.I E:System.AppDomain.AssemblyLoad
.TP
.I "F:"
شناسه رشته‌ای به یک فیلد اشاره دارد. نام فیلد پس از نام نوع می‌آید:
.I F:System.Runtime.InteropServices.DllImportAttribute.SetLastError
.TP
.I "M:"
به یک سازنده (constructor) یا متد اشاره دارد. سازنده‌ها عبارت
.I .ctor
را به نام نوع اضافه می‌کنند، در حالی که متدها نام متد را (همراه با تعداد اختیاری پارامترهای جنریک) پیوست می‌کنند.
.Sp
اگر سازنده یا متد آرگومان بپذیرد، این آرگومان‌ها درون پرانتز پس از نام سازنده/متد فهرست می‌شوند:
.Sp
.I M:System.Object..ctor
,
.I M:System.String..ctor(System.Char[])
,
.I M:System.String.Concat(System.Object)
,
.I M:System.Array.Sort``1(``0[])
,
.I M:System.Collections.Generic.List`1..ctor
,
.I M:System.Collections.Generic.List`1.Add(`0)
\&.
.TP
.I "N:"
به یک فضای نام (namespace) اشاره دارد، مانند
.I N:System
.TP
.I "P:"
به یک ویژگی (property) اشاره دارد. اگر ویژگی یک نمایه‌ساز (indexer) باشد یا پارامتر بپذیرد، انواع پارامترها به نام ویژگی پیوست شده و درون پرانتز قرار می‌گیرند:
.I P:System.String.Length
,
.I P:System.String.Chars(System.Int32)
\&.
.TP
.I "T:"
شناسه رشته‌ای به یک نوع اشاره دارد که تعداد انواع جنریک به آن پیوست شده است:
.I T:System.String
,
.I T:System.Collections.Generic.List`1
.PP
برای جالب‌تر شدن موضوع، انواع و اعضای جنریک دو نمایش دارند: نمایش «نامقید» (unbound) (که در مثال‌های بالا نشان داده شد)، که در آن تعداد پارامترهای جنریک به نام کلاس‌ها پیوست می‌شود. همچنین یک نمایش «مقید» (bound) وجود دارد که در آن انقیاد پارامترهای جنریک درون «{» و «}» فهرست می‌شود.
.PP
.B نامقید (Unbound):
.I T:System.Collections.Generic.List`1
,
.I T:System.Collections.Generic.Dictionary`2
\&.
.PP
.B مقید (Bound):
.I T:System.Collections.Generic.List{System.Int32}
.I T:System.Collections.Generic.Dictionary{System.String,System.Collections.Generic.List{System.Predicate{System.String}}}
\&.
.PP
همان‌طور که مشاهده می‌کنید، حالت‌های مقید می‌توانند به صورت دلخواه پیچیده باشند (درست مانند جنریک‌ها).
.PP
علاوه بر این، اگر یک پارامتر جنریک به پارامتر جنریک یک نوع یا متد مقید شده باشد، «شاخص» (index) پارامتر جنریک آن نوع/متد به عنوان انقیاد به کار می‌رود؛ بنابراین با فرض
.nf
	class FooType {
	  public static void Foo<T> (System.Predicate<T> predicate) {}
	}
.fi
شناسه رشته‌ای برای این متد عبارت است از
.I M:FooType.Foo``1(System.Predicate{``0})
، زیرا
.I ``0
شاخص صفرمین پارامتر جنریک است که به
.I System.Predicate<T>
مقید شده است\&..SH "قالب مستندسازی (DOCUMENTATION FORMAT)"
دستور
.I monodocer
مستنداتی مشابه با قالب مستندسازی Ecma تولید می‌کند، همان‌گونه که در ECMA-335 ویرایش ۳، بخش IV، فصل ۷ توصیف شده است.
.PP
تفاوت اصلی با قالب ECMA در این است که هر نوع (type) فایل اختصاصی خود را درون دایرکتوری‌ای هم‌نام با فضای نام (namespace) نوع دریافت می‌کند.
.PP
بیشتر اطلاعات موجود در مستندات
.I نباید
ویرایش شوند. این موارد شامل نام نوع (
.I /Type/@FullName
)، رابط‌های پیاده‌سازی‌شده (
.I /Type/Interfaces
)، اطلاعات اعضا (
.I /Type/Members/Member/@MemberName
،
.I /Type/Members/Member/MemberSignature
،
.I /Type/Members/Member/MemberType
،
.I /Type/Members/Member/Parameters
و غیره) است.
.PP
آنچه 
.I باید
تغییر یابد، تمامی عناصری با متن
.I To be added.
هستند که در زیر عناصر
.I //Docs
قرار دارند (مانند
.I /Type/Docs
،
.I /Type/Members/Member/Docs
). محتویات عنصر
.I Docs
از نظر معنایی و ساختاری
.I یکسان
با قالب مستندسازی درون‌کدی C# است که از این عناصر (فهرست‌شده در ECMA-334 ویرایش ۳، پیوست E، بخش ۲) تشکیل شده است. موارد زیر در توصیف عناصر به کار رفته‌اند:
.TP
.I CREF
به یک ارجاع به کلاس (یا عضو) اشاره دارد، و رشته‌ای در قالب شرح‌داده‌شده در بخش
.I STRING ID FORMAT
در بالا است.
.TP
.I TEXT
متن غیر XML است و XML نباید درون آن تودرتو شود.
.I
.TP
.I XML
تنها عناصر XML باید درون آن تودرتو شوند (که به‌طور غیرمستقیم ممکن است شامل متن باشند)، اما متن‌های غیر از فاصلهٔ خالی نباید گره فرزند مستقیم باشند.
.TP
.I XML_TEXT
متن آزاد و XML، به‌گونه‌ای که سایر عناصر XML می‌توانند درون آن تودرتو شوند.
.PP
عناصر زیر در مستندسازی استفاده می‌شوند:
.TP
.I <block subset="SUBSET" type="TYPE">XML_TEXT</block>
یک بلوک متنی ایجاد می‌کند که از نظر مفهومی شبیه به یک پاراگراف است، اما برای ایجاد بخش‌بندی درون متن استفاده می‌شود. تا حدودی، یک <block/> معادل برچسب HTML <h2/> است.
.Sp
.I SUBSET
همیشه باید دارای مقدار
.I "none"
\& باشد.
.Sp
.I TYPE
عنوان و قالب‌بندی مورد استفاده را مشخص می‌کند. انواع شناخته‌شده عبارتند از:
.Sp
.I behaviors
بخشی با عنوان
.I Operation
ایجاد می‌کند.
.Sp
.I note
بخشی با عنوان
.I Note:
ایجاد می‌کند.
.Sp
.I overrides
بخشی با عنوان
.I Note to Inheritors
ایجاد می‌کند.
.Sp
.I usage
بخشی با عنوان
.I Usage
ایجاد می‌کند.
.TP
.I <c>XML_TEXT</c>
متن را در قلمی شبیه به کد قرار می‌دهد (مشابه عنصر HTML <tt/>).
.TP
.I <code lang="LANGUAGE">TEXT</code>
چندین خط متن را در قلمی شبیه به کد نمایش می‌دهد (مشابه عنصر HTML <pre/>).
.I LANGUAGE
زبانی است که این بلوک کد برای آن در نظر گرفته شده است. برای مثال، اگر
.I LANGUAGE
برابر
.B C#
باشد، آن‌گاه
.I TEXT
در Mono Documentation Browser دارای برجسته‌سازی نحوی برای زبان C# خواهد شد.
.TP
.I <example>XML_TEXT</example>
مثالی را مشخص می‌کند که باید به‌صورت ویژه‌ای نمایش داده شود. برای مثال:
.nf
	<example>
	  <para>An introductory paragraph.</para>
	  <code lang="C#">
	    class Example {
	      public static void Main ()
	      {
	        System.Console.WriteLine ("Hello, World!");
	      }
	    }
	  </code>
	</example>
.fi
.TP
.I <exception cref="CREF">XML_TEXT</exception>
استثنایی را مشخص می‌کند که می‌تواند توسط عضو مستندشده پرتاب شود.
.Sp
.I <exception/>
یک عنصر سطح بالا است و باید مستقیماً در زیر عنصر
.I <Docs/>
قرار گیرد.
.Sp
.I CREF
نوع استثنایی است که پرتاب می‌شود، در حالی که
.I XML_TEXT
شامل شرایطی است که باعث پرتاب شدن
.I CREF
می‌شود.
.nf
	<exception cref="T:System.ArgumentNullException">
	  <paramref name="foo" /> was <see langword="null" />.
	</exception>
.fi
.TP
.I <list>XML</list>
یک فهرست یا جدول از موارد ایجاد می‌کند.
.I <list/>
از عناصر تودرتوی
.I <item>XML</item>
،
.I <listheader>XML</listheader>
،
.I <term>XML_TEXT</term>
و
.I <description>XML_TEXT</description>
استفاده می‌کند.
.Sp
.I فهرست‌ها
دارای این نحو هستند:
.nf
	<list type="bullet"> <!-- or type="number" -->
	  <item><term>Bullet 1</term></item>
	  <item><term>Bullet 2</term></item>
	  <item><term>Bullet 3</term></item>
	</list>
.fi
.Sp
.I جدول‌ها
دارای این نحو هستند:
.nf
	<list type="table">
	  <listheader> <!-- listheader bolds this row -->
	    <term>Column 1</term>
	    <description>Column 2</description>
	    <description>Column 3</description>
	  </listheader>
	  <item>
	    <term>Item 1-A</term>
	    <description>Item 1-B</description>
	    <description>Item 1-C</description>
	  </item>
	  <item>
	    <term>Item 2-A</term>
	    <description>Item 2-B</description>
	    <description>Item 2-C</description>
	  </item>
	</list>
.fi.TP
.I <para>XML_TEXT</para>
یک بند (پاراگراف) از
.I XML_TEXT
را درج می‌کند.
این برچسب برای استفاده درون برچسب‌های دیگر، مانند
.I <example/>
،
.I <remarks/>
،
.I <returns/>
،
.I <term/>
و
.I <description/>
(ببینید
.I <list/>
، در بالا)، و اکثر عناصر دیگر است.
.Sp
برای مثال:
.nf
	<para>This is a paragraph of text.</para>
.fi
.TP
.I <param name="NAME">XML_TEXT</param>
.I <param/>
یک عنصر سطح‌بالا است و باید مستقیماً زیر عنصر
.I <Docs/>
قرار گیرد.
.Sp
پارامتر
.I NAME
را برای سازنده (constructor)، متد، یا ویژگی (property) فعلی شرح می‌دهد:
.nf
	<param name="count">
	  A <see cref="T:System.Int32" /> containing the number
	  of widgets to process.
	</param>
.fi
.TP
.I <paramref name="NAME" />
مشخص می‌کند که
.I NAME
یک پارامتر است.
.Sp
این برچسب معمولاً
.I NAME
را به‌صورت متن مورب (italic) نمایش می‌دهد، بنابراین مکرراً به عنوان معادل عنصر HTML <i/> مورد استفاده (یا سوءاستفاده) قرار می‌گیرد. برای یک مثال، به مستندات
.I <exception/>
(در بالا) مراجعه کنید.
.TP
.I <permission cref="CREF">XML_TEXT</permission>
الزامات دسترسی امنیتی عضو فعلی را مستند می‌کند.
.Sp
.I <permission/>
یک عنصر سطح‌بالا است و باید مستقیماً زیر عنصر
.I <Docs/>
قرار گیرد.
.Sp
.I CREF
یک ارجاع نوع (type reference) به مجوز امنیتی مورد نیاز است، در حالی که
.I XML_TEXT
توضیحی درباره دلیل نیاز به این مجوز است.
.nf
	<permission cref="T:System.Security.Permissions.FileIOPermission">
	  Requires permission for reading and writing files. See 
	  <see cref="F:System.Security.Permissions.FileIOPermissionAccess.Read" />, 
	  <see cref="F:System.Security.Permissions.FileIOPermissionAccess.Write" />.
	</permission>
.fi
.TP
.I <remarks>XML_TEXT</remarks>
حاوی اطلاعات تفصیلی درباره یک عضو است.
.Sp
.I <remarks/>
یک عنصر سطح‌بالا است و باید مستقیماً زیر عنصر
.I <Docs/>
قرار گیرد.
.nf
	<remarks>Insert detailed information here.</remarks>
.fi
.TP
.I <returns>XML_TEXT</returns>
.Sp
.I <remarks/>
یک عنصر سطح‌بالا است و باید مستقیماً زیر عنصر
.I <Docs/>
قرار گیرد.
.Sp
مقدار بازگشتی یک متد را شرح می‌دهد:
.nf
	<returns>
	  A <see cref="T:System.Boolean" /> specifying whether 
	  or not the process can access 
	  <see cref="P:Mono.Unix.UnixFileSystemInfo.FullName" />.
	</returns>
.fi
.TP
.I <see cref="CREF" />
پیوندی به عضو مشخص‌شده درون متن فعلی ایجاد می‌کند:
.nf
	<see cref="M:Some.Namespace.With.Type.Method" />
.fi
.TP
.I <seealso cref="CREF" />
.Sp
.I <seealso/>
یک عنصر سطح‌بالا است و باید مستقیماً زیر عنصر
.I <Docs/>
قرار گیرد.
.Sp
امکان ایجاد یک مدخل را برای زیربخش
.I See Also
فراهم می‌سازد. از
.I <see/>
برای مشخص کردن پیوند از درون متن استفاده کنید.
.nf
	<seealso cref="P:System.Exception.Message" />
.fi
.TP
.I <since version="VERSION" />
.Sp
.I <since/>
یک عنصر سطح‌بالا است و باید مستقیماً زیر عنصر
.I <Docs/>
قرار گیرد.
.Sp
امکان مشخص کردن این که کدام نسخه، نوع یا عضو مشخص‌شده را معرفی کرده است فراهم می‌کند.
.nf
	<since version="Gtk# 2.4" />
.fi
.TP
.I <summary>DESCRIPTION</summary>
.Sp
.I <summary/>
یک عنصر سطح‌بالا است و باید مستقیماً زیر عنصر
.I <Docs/>
قرار گیرد.
.Sp
یک نمای کلی (مختصر!) درباره یک نوع یا عضو نوع ارائه می‌دهد.
.Sp
این عنصر معمولاً به عنوان بخشی از اعلان کلاس نمایش داده می‌شود و باید شرحی به‌طور معقول کوتاه از نوع/عضو باشد. برای اطلاعات تفصیلی‌تر از
.I <remarks/>
استفاده کنید.
.TP
.I <typeparam name="NAME">DESCRPITION</typeparam>
.I <typeparam/>
یک عنصر سطح‌بالا است و باید مستقیماً زیر عنصر
.I <Docs/>
قرار گیرد.
.Sp
این برچسب برای توصیف پارامتر نوع در یک نوع عمومی (generic) یا متد عمومی استفاده می‌شود.
.Sp
.I NAME
نام پارامتر نوع است، در حالی که
.I DESCRIPTION
شامل شرحی از پارامتر است (برای چه کاری استفاده می‌شود، چه محدودیت‌هایی را باید رعایت کند و غیره).
.nf
	<typeparam name="T">The type of the underlying collection</typeparam>
.fi
.TP
.I <typeparamref>
برای مشخص کردن این‌که یک کلمه پارامتر نوع است به کار می‌رود؛ جهت استفاده درون سایر بلوک‌های متنی (مثلاً درون
.I <para/>
).
.nf
	<para>If <typeparamref name="T" /> is a struct, then...</para>
.fi
.TP
.I <value>DESCRIPTION</value>
.I <value/>
یک عنصر سطح‌بالا است و باید مستقیماً زیر عنصر
.I <Docs/>
قرار گیرد.
.Sp
امکان توصیف یک ویژگی (property) را فراهم می‌کند..nf
	<value>
	  A <see cref="T:System.String" /> containing a widget name.
	</value>
.fi
.PP
.SH "همچنین ببینید (SEE ALSO)"
mdassembler(1), mdcs2ecma(1), mdnormalizer(1), mdvalidator(1), monodocs2html(1)
.SH "فهرست‌های پستی (MAILING LISTS)"
.TP
برای جزئیات بیشتر به http://lists.ximian.com/mailman/listinfo/mono-docs-list مراجعه کنید.
.SH "وبگاه (WEB SITE)"
برای جزئیات بیشتر به http://www.mono-project.com مراجعه کنید.