s.property.value

Purpose

The s.property.value annotation is used to tag a span element as being the value of a property. It will associate this value with a preceding property type and/or a following property description.

The property value acts as the name or status of a specific property within its type.

Examples

The following is an example of a time where you might want to use the s.property.value annotation:

Note: the relevant span has been marked in bold for this example. The span is not bold in the source document.

The following is an example of a rule that will apply s.property.value:

The following is an example of the DITA output you would get from this annotation.

<property>

<proptype>Input  </proptype>

<propvalue>None  </propvalue>

<propdesc>This function does not take user input.</propdesc>

</property>

<property>

<proptype>Output  </proptype>

<propvalue>None  </propvalue>

<propdesc>This function does not produce output.</propdesc>

</property>

<property>

<proptype>Arguments  </proptype>

<propvalue>Two  </propvalue>

<propdesc>This function takes two arguments: item and range.</propdesc>

</property>

The post s.property.value appeared first on Stilo.

s.property.type

Purpose

The s.property.type annotation is used to tag a span element as being the type of a property. It will associate this type with a following property value and/or description.

The property type acts as a category for properties.

Examples

The following is an example of a time where you might want to use the s.property.type annotation:

Note: the relevant span has been marked in bold for this example. The span is not bold in the source document.

The following is an example of a rule that will apply s.property.type:

The following is an example of the DITA output you would get from this annotation.

<property>

<proptype>Input  </proptype>

<propvalue>None  </propvalue>

<propdesc>This function does not take user input.</propdesc>

</property>

<property>

<proptype>Output  </proptype>

The post s.property.type appeared first on Stilo.

s.property.head.type

Purpose

The s.property.head.type annotation is used to tag a span element as being the header type of a property. It will associate this type with a following property header value and/or description.

The property header type acts as the header for a type column in a properties table.

Examples

The following is an example of a time where you might want to use the s.property.head.type annotation:

Note: the relevant span has been marked in bold for this example. The span is not bold in the source document.

The following is an example of a rule that will apply s.property.head.type:

The following is an example of the DITA output you would get from this annotation.

<properties>

<prophead>

<proptypehd>Property</proptypehd>

<propvaluehd>Value</propvaluehd>

<propdeschd>Description</propdeschd>

</prophead>

The post s.property.head.type appeared first on Stilo.

s.property.head.description

Purpose

The s.property.head.description annotation is used to tag a span element as being the header description of a property. It will associate this description with a preceding property header type and/or value.

The property header description acts as the header for a description column in a properties table.

Examples

The following is an example of a time where you might want to use the s.property.head.description annotation:

This content will be organized into a simple table format. The p.simpletable.head annotation will be used to mark the first row (Date | Significance | Region) as the header row.

Note: the relevant span has been marked in bold for this example. The span is not bold in the source document.

The following is an example of a rule that will apply s.property.head.description:

The following is an example of the DITA output you would get from this annotation.

<properties>

<prophead>

<proptypehd>Property</proptypehd>

<propvaluehd>Value</propvaluehd>

<propdeschd>Description</propdeschd>

</prophead>

The post s.property.head.description appeared first on Stilo.

p.property.head

Purpose

The p.property.head annotation is used to tag an element as being a header for a properties table. This annotation allows the grouping of span header property elements into a single <prophead> tag. The content does not need to be contained in a table in the source document.

Examples

The following is an example of a time where you might want to use the p.property.head annotation:

Note: the relevant paragraph has been marked in bold for this example. The paragraph is not bold in the source document.

The following is an example of a rule that will apply p.property.head:

The following is the DITA XML output for the previous rule:

<properties>

<prophead>

            <proptypehd>Property</proptypehd>

<propvaluehd>Value</propvaluehd>

<propdeschd>Description</propdeschd>

         </prophead>

<property>

<proptype>Input  </proptype>

<propvalue>None  </propvalue>

<propdesc>This function does not take user input.</propdesc>

</property>

<property>

<proptype>Output  </proptype>

<propvalue>None  </propvalue>

<propdesc>This function does not produce output.</propdesc>

</property>

<property>

<proptype>Arguments  </proptype>

<propvalue>Two  </propvalue>

<propdesc>This function takes two arguments: item and range.</propdesc>

</property>

</properties>

The post p.property.head appeared first on Stilo.

p.reference.syntax

Purpose

The p.reference.syntax annotation is used to tag an element as being an example of code syntax. This will be a generic form of the code, function, or other programming component.

Examples

The following is an example of a time where you might want to use the p.reference.syntax annotation:

Note: the relevant paragraph has been marked in bold for this example. The paragraph is not bold in the source document.

The following is an example of a rule that will apply p.reference.syntax:

Note: the p.code annotation is also applied to this paragraph. See p.code for more information.

The following is the DITA XML output for the previous rule:

<refsyn><codeblock>for item in range:</codeblock></refsyn>

The post p.reference.syntax appeared first on Stilo.

related-link((href=link)(type=target)(format=format)(scope=scope)(linktext=linktext)(desc=desc)(retain-content=))

href (optional)

the location of the target of the cross-reference. Must be in valid URI format.

type (optional)

describes the target of a cross-reference. Some possible values are fig, table, li, fn, section, concept, task, reference, topic, (no value).

format (optional)

format of the resource being linked to. Possible values are dita, html, pdf.

scope (optional)

describes the closeness of the relationship between the current document and the target. Possible values are local, peer, external.

linktext (optional)

the literal text for a link. Not needed for local links unless the local link is not in DITA format; needed for peer or external links.

desc (optional)

description of the element being cross-referenced.

retain-content (optional)

indicates whether or not the link text will be displayed. Possible values are true or false.

Purpose

The order of the parameters is important; you do not have to use all of the parameters, but those that you do use must be in the order listed here.

Migrate will fill in the href and linktext by default, even if you do not specify them in the annotation. If you have text like the following in your document:

You could use the following rule, which does not specify either the href or the linktext:

You would get the following for output.

<related-links>
  <link href="issue_3__task_procedure_authored_as_a_table_in_the_input_file.dita">
    <linktext>Issue 3: Task/Procedure authored as a table in the input file</linktext>
    <desc>Issue 3: Task/Procedure authored as a table in the input file</desc>
  </link>
  <link href="issue_6__a_definition_list_is_coded_as_a_table.dita">
    <linktext>Issue 6: A definition list is coded as a table</linktext>
    <desc>Issue 6: A definition list is coded as a table</desc>
  </link>
</related-links>

The following rule illustrates all of the parameters in use:

You would get the following for output.

  <p outputclass="ID-000002ae" otherprops="Online">Related Topics</p> 
  <xref outputclass="ID-0000013b" href="issue_3__task_procedure_authored_as_a_table_in_the_input_file.dita">
    Issue 3: Task/Procedure authored as a table in the input file
  </xref>
  <xref outputclass="ID-0000013b" href="issue_6__a_definition_list_is_coded_as_a_table.dita">
    Issue 6: A definition list is coded as a table
  </xref>
</conbody>
<related-links>
  <link href="ID-2316-000002fe" type="topic" format="dita" scope="local">
    <linktext>Issue 3: Task/Procedure authored as a table in the input file</linktext>
    <desc>Issue 3: Task/Procedure authored as a table in the input file</desc>
  </link>
  <link href="ID-2316-00000340" type="topic" format="dita" scope="local">
    <linktext>Issue 6: A definition list is coded as a table</linktext>
    <desc>Issue 6: A definition list is coded as a table </desc>
  </link>
</related-links>

The following rule illustrates all of the parameters in use, this time with retain-content set to false:

You would get the following for output.

  <p outputclass="ID-000002ae" otherprops="Online">Related Topics</p>
</conbody>
<related-links>
  <link href="ID-2316-000002fe" type="topic" format="dita" scope="local">
    <linktext>Issue 3: Task/Procedure authored as a table in the input file</linktext>
    <desc>Issue 3: Task/Procedure authored as a table in the input file</desc>
  </link>
  <link href="ID-2316-00000340" type="topic" format="dita" scope="local">
    <linktext>Issue 6: A definition list is coded as a table</linktext>
    <desc>Issue 6: A definition list is coded as a table</desc>
  </link>
</related-links>

This rule shows you how to specify no parameters at all, which will cause Migrate to fill in the defaults for href and linktext.

  <p outputclass="ID-000002ae" otherprops="Online">Related Topics</p>
</conbody>
<related-links>
  <link href="issue_3__task_procedure_authored_as_a_table_in_the_input_file.dita">
    <linktext>Issue 3: Task/Procedure authored as a table in the input file</linktext>
  </link>
  <link href="issue_6__a_definition_list_is_coded_as_a_table.dita">
    <linktext>Issue 6: A definition list is coded as a table</linktext>
  </link>
</related-links>

The post related-link appeared first on Stilo.

reltable-entry((href=link)(navtitle=title)(scope=scope)(format=format)(shortdesc=text)(retain-content=))

href (optional)

the location of the target of the cross-reference. Must be in valid URI format.

navtitle (optional)

scope (optional)

describes the closeness of the relationship between the current document and the target. Possible values are local, peer, external.

format (optional)

format of the resource being linked to. Possible values are dita, html, pdf.

shortdesc (optional)

used to provide information about a non-DITA object.

retain-content (optional)

indicates whether or not the link text will be displayed. Possible values are true or false.

Purpose

The order of the parameters is important; you do not have to use all of the parameters, but those that you do use must be in the order listed here.

Relationship tables specify relationships between topics in a document. These relationships are placed in a table so links between topics are easy to see.

This rule shows you how to specify no parameters at all for your reltable entry. One important thing to remember with the reltable-entry annotation is that, by default, it will remove the content to which it is applied. If you want the content to remain in place, you need to specify retain-content=true.

You would get the following output, which is the default that Migrate will provide without parameters specified:

<reltable id="reltable_8A1A41B98B73448BB016C7D532C8E57C">
  <relheader>
    <relcolspec linking="sourceonly"/>
    <relcolspec type="topic"/>
    <relcolspec type="concept"/>
    <relcolspec type="task"/>
    <relcolspec type="reference"/>
  </relheader>
  <relrow>
    <relcell>
      <topicref href="organization.dita" type="concept" navtitle="Organization" linking="sourceonly"/>
    </relcell>
    <relcell/>
    <relcell>
    <topicref href="hardware_requirements.dita" type="concept"
              navtitle="Hardware Requirements" linking="targetonly"/>
    </relcell>
    <relcell/>
    <relcell/>
  </relrow>
  <relrow>
    <relcell>
      <topicref href="organization.dita" type="concept" navtitle="Organization" linking="sourceonly"/>
    </relcell>
    <relcell/>
    <relcell>
      <topicref href="organization.dita" type="concept" navtitle="Organization" linking="targetonly"/>
    </relcell>
    <relcell/>
    <relcell/>
  </relrow>
  <relrow>
    <relcell>
      <topicref href="chapter_1_preface.dita" type="concept" navtitle="Preface" linking="sourceonly"/>
    </relcell>
    <relcell/>
    <relcell>
      <topicref href="about_this_document.dita" type="concept"
                navtitle="About this document" linking="targetonly"/>
    </relcell>
    <relcell/>
    <relcell>
  </relrow>
  <relrow>
    <relcell>
      <topicref href="chapter_1_preface.dita" type="concept" navtitle="Preface" linking="sourceonly"/>
    </relcell>
    <relcell/>
    <relcell>
      <topicref href="further_reading.dita" type="concept" navtitle="Further reading" linking="targetonly"/>
    </relcell>
    <relcell/>
    <relcell>
  </relrow>
</reltable>

The following rule illustrates all of the parameters in use and retain-content set to true:

You would get the following for output.

<reltable id="reltable_8A5158A55D3746B1BC23F11F44205F6D">
  <relheader>
    <relcolspec linking="sourceonly"/>
    <relcolspec type="topic"/>
    <relcolspec type="concept"/>
    <relcolspec type="task"/>
    <relcolspec type="reference"/>
    <relcolspec type=""/>
  </relheader>
  <relrow>
    <relcell>
      <topicref href="organization.dita" type="concept" navtitle="Organization" linking="sourceonly"/>
    </relcell>
    <relcell/>
    <relcell/>
    <relcell/>
    <relcell/>
    <relcell>
      <topicref href="topics.xml" type="" navtitle="page 6" scope="local" format="dita" linking="targetonly">
        <topicmeta> <shortdesc>page 6</shortdesc></topicmeta>
      </topicref>
    </relcell>
  </relrow>
  <relrow>
    <relcell>
      <topicref href="chapter_1_preface.dita" type="concept" navtitle="Preface" linking="sourceonly"/>
    </relcell>
    <relcell/>
    <relcell/>
    <relcell/>
    <relcell/>
    <relcell>
      <topicref href="topics.xml" type="" navtitle="About this document"
                scope="local" format="dita" linking="targetonly">
        <topicmeta>
          <shortdesc>About this document</shortdesc>
      </topicmeta>
      </topicref>
    </relcell>
  </relrow>
</reltable>

The following rule illustrates all of the parameters in use, this time with retain-content set to false:

You would get the following for output.

<reltable id="reltable_8662CFAE8C934A679B818BD6EB1FA8AE">
  <relheader>
    <relcolspec linking="sourceonly"/>
    <relcolspec type="topic"/>
    <relcolspec type="concept"/>
    <relcolspec type="task"/>
    <relcolspec type="reference"/>
    <relcolspec type=""/>
  </relheader>
<relrow>
  <relcell>
    <topicref href="organization.dita" type="concept" navtitle="Organization" linking="sourceonly"/>
  </relcell>
  <relcell/>
  <relcell/>
  <relcell/>
  <relcell/>
  <relcell>
    <topicref href="page 6" type="" navtitle="page 6" scope="local" format="dita" linking="targetonly">
      <topicmeta>
        <shortdesc>page 6</shortdesc>
      </topicmeta>
    </topicref>
  </relcell>
</relrow>
<relrow>
  <relcell>
    <topicref href="organization.dita" type="concept" navtitle="Organization" linking="sourceonly"/>
  </relcell>
  <relcell/>
  <relcell/>
  <relcell/>
  <relcell/>
  <relcell>
    <topicref href="Chapter 4 - Common problems with document conversion" type=""
              navtitle="Chapter 4 - Common problems with document conversion"
              scope="local" format="dita" linking="targetonly">
      <topicmeta>
        <shortdesc>Chapter 4 - Common problems with document conversion</shortdesc>
      </topicmeta>
    </topicref>
  </relcell>
</relrow>
<relrow>
  <relcell>
    <topicref href="chapter_1_preface.dita" type="concept" navtitle="Preface" linking="sourceonly"/>
  </relcell>
  <relcell/>
  <relcell/>
  <relcell/>
  <relcell/>
  <relcell>
    <topicref href="About this document" type="" navtitle="About this document"
              scope="local" format="dita" linking="targetonly">
      <topicmeta>
        <shortdesc>About this document</shortdesc>
      </topicmeta>
    </topicref>
  </relcell>
</relrow>
<relrow>
  <relcell>
    <topicref href="chapter_1_preface.dita" type="concept" navtitle="Preface" linking="sourceonly"/>
  </relcell>
  <relcell/>
  <relcell/>
  <relcell/>
  <relcell/>
  <relcell>
    <topicref href="Further reading" type="" navtitle="Further reading"
              scope="local" format="dita" linking="targetonly">
      <topicmeta>
        <shortdesc>Further reading</shortdesc>
      </topicmeta>
    </topicref>
  </relcell>
</relrow>
</reltable>

The post reltable-entry appeared first on Stilo.

conref((key=keyname)(id-for-the-library=libraryid)(filename=filename)(content=texttoconref)(topic-type=type))

key

short label used to identify the text being referenced

id-for-the-library (optional)

the file ID for your conref file

filename (optional)

name for your file; this file will be included in your DITA output

content (optional)

the text that will replace the conref in the published document

topic-type (optional)

type of topic for your library file

conkeyref((key=keyname)(id-for-the-library=libraryid)(filename=filename)(content=texttoconkeyref)(topic-type=type))

key

short label used to identify the text being referenced

id-for-the-library (optional)

the file ID for your conkeyref file

filename (optional)

name for your file; this file will be included in your DITA output

content (optional)

the text that will replace the conkeyref in the published document

topic-type (optional)

type of topic for your library file

If you use the argument topic-type, you must also use the argument id-for-the-library in your annotation.

Purpose

These commands operate in a similar way; they allow you to easily reuse content. The difference between a conref and a conkeyref is in how the content being brought into your document is referenced, or located.

A conref requires a URI-based, or direct, reference to the content being pulled in. (For more information on URI-based addressing, please see the DITA specification for URI-based addressing.) For example, using a conref to replace the variable CompanyName with the company name Birds Eye Inc would give you a rule that looks like this:

You will get output in your topic that may look like the following:

<p>
  Words and logos marked with ® or ™ are registered trademarks or 
  trademarks owned by 
  <ph conref="BirdsEyeConrefs.dita#BirdsEyeConrefs/CompanyName">
    Birds Eye Inc
  </ph>.
  Other brands and names mentioned herein may be the trademarks of 
  their respective owners.
</p>

A conkeyref uses an indirect method to access the content being pulled in. Using a conkeyref to replace the variable CompanyName with the company name Birds Eye Inc would give you a rule that looks like this:

This may give you the following output in your topic:

<p>
  Words and logos marked with ® or ™ are registered trademarks or 
  trademarks owned by
  <ph conkeyref="BirdsEyeConrefs/CompanyName">
    Birds Eye Inc
  </ph>. 
  Other brands and names mentioned herein may be the trademarks of 
  their respective owners.
</p>

The post conref(), conkeyref() annotations appeared first on Stilo.