Make your own free website on Tripod.com

pattern.dtd
[rev 0.3 Beta 1998.07.06]

A Draft DTD for Documenting Patterns with XML

This is the 0.3beta version of Rod's pattern.dtd. Comments and a pointer to the most recent version can be found at members.tripod.com/~rwald/patterns/pat_dtd.html. (As of this writing, this is the most recent version.)

An example of using this DTD to mark-up a pattern, together with some example renderings of that markup is available.

This document is members.tripod.com/~rwald/patterns/pat_dtd_0_3_beta.html. Please send any comments, complaints or suggestions to rod@pg.net or rwald@hotmail.com.

Changes from Revision 0.2 [pat_dtd_0_2.html]:


<!--
###############################################################################
#  PATTERN.DTD                                                                #
###############################################################################
#   filename: pattern.dtd                                                     #
#                                                                             #
#   A draft Document Type Definition for writing patterns in XML.             #
#                                                                             #
#   Revision #0.3 beta 1998.06.29                                             #
#   Rodney Waldhoff <rod@pg.net>;<rwald@hotmail.com>                          #
###############################################################################
-->

<!--
###############################################################################
#  GENERIC DECLARATIONS                                                       #
###############################################################################
#  This section defines entities used throughout the document.                #
###############################################################################
 -->

<!--
   The xrefs entity simply groups the reference (link) related elements.
 -->
<!ENTITY % xrefs "%link.name; | %citeref.name;">

<!--
   The xrefs.pat entity adds patref to the list of xref elements.
 -->
<!ENTITY % xrefs.pat "%xrefs; | %patref.name;">

<!--
   The xrefs.custom entity allows extensions to the xrefs entity
 -->
<!ENTITY % xrefs.custom "">

<!--
   The xrefs.all entity groups xrefs and xrefs.custom into a
   single entity.
 -->
<!ENTITY % xrefs.all "%xrefs; %xrefs.custom;>

<!--
   The xrefs.pat.all entity groups xrefs.pat and xrefs.custom into a
   single entity.
 -->
<!ENTITY % xrefs.pat.all "%xrefs.pat; %xrefs.custom;>

<!--
   The textstyle entity describes the basic text-style modifiers, as in
   HTML.  Note that, as in HTML 4, the U tag is not allowed.
   Also, BIG and SMALL are not allowed.
   The SUB and SUP tags have been moved to another entity.
 -->
<!ENTITY % textstyle "%b.name; | %i.name; | %tt.name;">

<!--
   The textstyle.custom entity is provided for easy extensions to
   textstyle.
 -->
<!ENTITY % textstyle.custom "">

<!--
   The textstyle.all entity is the union of textstyle and textstyle.custom.
 -->
<!ENTITY % textstyle.all "%textstyle; %textstyle.custom;">

<!--
   The textpos entity describes the basic text-position modifiers.
 -->
<!ENTITY % textstyle "%sub.name; | %sup.name;">

<!--
   The textpos.custom entity is provided for easy extensions to
   textpos.
 -->
<!ENTITY % textpos.custom "">

<!--
   The textpos.all entity is the union of textpos and textpos.custom.
 -->
<!ENTITY % textpos.all "%textpos; %textpos.custom;">


 
<!-- ###################################################################### -->

<!--
###############################################################################
#  MISCELLANEOUS DECLARATIONS                                                 #
###############################################################################
#  This section defines some misc. elements used below.                       #
###############################################################################
 -->


<!--
   The <link> element identifies a cross-reference to an online document.

   The href attribute identifies the address (which should include the
   protocol specification (http:,ftp:wais:,etc.)).
   The body of the element is the text that is linked, or a label to use.

   This element is intended to comply with the working draft of the
   XML Linking Language standard (www.w3.org/TR/)
 -->

<!-- uselink: a switch to include or ignore the link declaration.
              You can override this value with 'IGNORE' to leave out the
              standard link declaration.
-->
<!ENTITY % uselink 'INCLUDE' >

<!ENTITY % link.name "link" >
<!ENTITY % link.href.name "href" >

<![%uselink;[ <!-- begin conditional section for link -->

<!ENTITY % link.content.custom "" >
<!ELEMENT %link.name; (generic.content.fontstyle.all
                       %link.content.custom;)*>

<!ENTITY % link.attr.custom "" >
<!ATTLIST link p_eltname       CDATA #FIXED        "link"
               %link.href.name CDATA #REQUIRED
               XML-LINK        CDATA #FIXED        "SIMPLE"
               ROLE            CDATA #IMPLIED
               TITLE           CDATA #IMPLIED
               INLINE          (TRUE|FALSE)        "TRUE"
               CONTENT-ROLE    CDATA #IMPLIED
               CONTENT-TITLE   CDATA #IMPLIED
               SHOW            (EMBED|REPLACE|NEW) "REPLACE"
               ACTUATE         (AUTO|USER)         "USER"
               BEHAVIOR        CDATA #IMPLIED
               XML-ATTRIBUTES  CDATA #FIXED        "HREF %link.href.name;"
               %link.attr.custom;
>

]]> <!-- end conditional section for link -->

<!-- ###################################################################### -->

<!--
   The <email> element specifies an email address.
   In HTML, this is likely to be rendered as a mailto href.

   Note that all email address attibutes allow comma separated lists
   of addresses.

   The to attribute specifies the RCPT TO part of the email.

   The cc attribute allows the writer to specify the CC part of
   of the email.

   The bcc attribute allows the writer to specify the BCC part of
   of the email.

   The subject attribute allows the writer to specify the SUBJECT part of
   of the email.

   The body attribute allows the writer to specify the BODY part of
   of the email.

   The content of the tag is the text used for the link.

   Note that in HTML you can render all this as:
   <A HREF="mailto:__&subject=__&cc=__&bcc=__&body=__">content</A>

   Notes:
    · Should this element be replaced by some XLL structure?
    · Is "addr" or "address" preferable to "to"?
    · Is "rcpt to" preferable to "to"?
 -->

<!-- useemail: a switch to include or ignore the email declaration.
              You can override this value with 'IGNORE' to leave out the
              standard email declaration.
-->
<!ENTITY % useemail 'INCLUDE' >

<!-- email.name: the name of the email element.

                 If you wish to replace this href element with a similar
                 structure, be sure to override this entity with the name of
                 the replacing tag and set usehref to IGNORE.

                 Otherwise you may change the name of the email tag by over-
                 riding the value of this entity.

                 For compatiblity, any email replacement must contain
                 an attribute to that defines the address to mail to,
                 and an attribute p_eltname that equals email.
-->
<!ENTITY % email.name "email" >
<!ENTITY % email.to.name "to" >
<![%useemail;[ <!-- begin conditional section for email -->

<!ENTITY % email.content.custom "" >
<!ELEMENT %email.name; (%generic.content.fontstyle.all;
                        %email.content.custom;)*>
<!ENTITY % email.attr.custom "" >
<!ATTLIST email p_eltname             CDATA #FIXED   "email"
                %email.to.name;       CDATA #REQUIRED
                cc                    CDATA #IMPLIED
                bcc                   CDATA #IMPLIED
                subject               CDATA #IMPLIED
                body                  CDATA #IMPLIED
                %email.attr.custom;
>

]]> <!-- end conditional section for email -->

<!-- ###################################################################### -->


<!-- ?????????????????????????????????????????????????????????????????????  -->

<!--
   The <biblio> element describes bibliographic data.
   Note:
    · There is probably a standard for biblio references like this.
      (I'm leaving it as "ANY" for now.)
 -->
<!ELEMENT biblio ANY>
<!ATTLIST biblio id #ID #required>

<!--
   The <citeref> element is used to create reference to a citation,
   i.e. for footnotes or endnotes.

   Note:
    · There is probably a standard for biblio references like this.
      (I'm leaving it as "ANY" for now.)
 -->
<!ELEMENT biblioref ANY>
<!ATTLIST biblioref biblioid #IDREF #required>

<!--
   It seems like some xref to previous versions of a document would be useful.
   Suggestions? Standards?
   Utilizing XLL?
 -->

<!-- ?????????????????????????????????????????????????????????????????????  -->


<!--
###############################################################################
#  FRONT MATTER                                                               #
###############################################################################
#  This describes some meta-information about the pattern or language.        #
#  This section will likely be broken out to a seperate DTD for easy          #
#  replacement.                                                               #
###############################################################################
 -->
<!-- usefront: a switch to include or ignore the front matter declaration.
               You can override this value with 'IGNORE' to leave out the
               standard front-matter declaration.
-->
<!ENTITY % usefront 'INCLUDE' >

<![%usefront;[ <!-- begin conditional section for front matter -->

<!ENTITY % front.name "front" >
<!ENTITY % front.content "%author.name;*, %version.name;?,
                          %copyright.name;?" >
<!ENTITY % front.content.custom "" >
<!ELEMENT %front.name; (%front.content; %front.content.custom;) >
<!ENTITY % front.attr.custom "" >
<!ATTLIST %front.name;  p_elttype CDATA #FIXED "front"
                        %front.attr.custom;
>

<!-- ###################################################################### -->

<!--
   The <author> element describes (one of) the document's author(s).

   An author is either a person or an organization.

   When an author is a person, the author section is composed of the following
   elements:
      · exactly one proper name <propername>
      · zero or more email addresses <email>
      · zero or more links <link>
      · zero or more descriptions of the author's organization <orgdescr>

   When an author is an organization, the author section is composed of exactly
   one <orgdescr>.
 -->
<!ENTITY % author.name "author" >
<!ENTITY % author.content "((%propername.name;+, %email.name;*, %link.name;*,
                             %orgdescr.name;*) | %orgdescr.name)" >
<!ENTITY % author.content.custom "" >
<!ELEMENT %author.name; (%author.content; %author.content.custom;) >
<!ENTITY % author.attr.custom "" >
<!ATTLIST %author.name;  p_elttype CDATA #FIXED "author"
                         %author.attr.custom;
>
<!-- ###################################################################### -->

<!--
   The <propername> element is used to identify a humans's proper name.
 -->
<!ENTITY % propername.name "propername" >
<!ENTITY % propername.content "%firstname.name;*, %middlename.name;*,
                               %surname.name;, suffix?, %altpropername.name;*"
>
<!ENTITY % propername.content.custom "" >
<!ELEMENT %propername.name; (%propername.content; %propername.content.custom;)>
<!ENTITY % propername.attr.custom "" >
<!ATTLIST %propername.name; p_elttype CDATA #FIXED "propername"
                            %propername.attr.custom;
>

<!-- ###################################################################### -->

<!--
   The <altpropername> element is used to specified aliases this person might
   have once used, e.g., a maiden name, or to identify alternate spellings.

   See <propername>.
 -->
<!ENTITY % altpropername.name "altpropername" >
<!ENTITY % altpropername.content "firstname*, middlename*, surname, suffix?" >
<!ENTITY % altpropername.content.custom "" >
<!ELEMENT %altpropername.name; (%altpropername.content;
                                %altpropername.content.custom;)>
<!ENTITY % altpropername.attr.custom "" >
<!ATTLIST %altpropername.name; p_elttype CDATA #FIXED "altpropername"
                               %altpropername.attr.custom;
>

<!-- ###################################################################### -->

<!--
   The <surname>, <firstname>, <middlename> and <suffix> elements identify
   the parts of a proper name.

   Note that these tags currently do not allow custom content models.
 -->
<!ENTITY % firstname.name "firstname" >
<!ELEMENT %firstname.name; (#PCDATA)>
<!ENTITY % firstname.attr.custom "" >
<!ATTLIST %firstname.name; p_elttype CDATA #FIXED "firstname"
                           %firstname.attr.custom;
>

<!ENTITY % middlename.name "middlename" >
<!ELEMENT %middlename.name; (#PCDATA)>
<!ENTITY % middlename.attr.custom "" >
<!ATTLIST %middlename.name; p_elttype CDATA #FIXED "middlename"
                            %middlename.attr.custom;
>

<!ENTITY % surname.name "surname" >
<!ELEMENT %surname.name; (#PCDATA)>
<!ENTITY % surname.attr.custom "" >
<!ATTLIST %surname.name; p_elttype CDATA #FIXED "surname"
                         %surname.attr.custom;
>

<!ENTITY % suffix.name "suffix" >
<!ELEMENT %suffix.name; (#PCDATA)>
<!ENTITY % suffix.attr.custom "" >
<!ATTLIST %suffix.name; p_elttype CDATA #FIXED "suffix"
                         %suffix.attr.custom;
>

<!-- ###################################################################### -->

<!--
   The <orgdescr> element describes an organization.
   Organizations must specify a name, and may provide zero or more urls.

    · Is this data sufficient?
    · Is there a need for more than one name?
    · Perhaps allow for #PCDATA?
    · Is there a better standard for this?
 -->
<!ENTITY % orgdescr.name "orgdescr" >
<!ENTITY % orgdescr.content "%orgname.name;, %link.name;*" >
<!ENTITY % orgdescr.content.custom "" >
<!ELEMENT %orgdescr.name; (%orgdescr.content;
                           %orgdescr.content.custom;)>
<!ENTITY % orgdescr.attr.custom "" >
<!ATTLIST %orgdescr.name; p_elttype CDATA #FIXED "orgdescr"
                          %orgdescr.attr.custom;
>

<!--
   The <orgname> element names an organization.
 -->
<!ENTITY % orgname.name "orgname" >
<!ENTITY % orgname.content "#PCDATA" >
<!ENTITY % orgname.content.custom "" >
<!ELEMENT %orgname.name; (%orgname.content;
                          %orgname.content.custom;)>
<!ENTITY % orgname.attr.custom "" >
<!ATTLIST %orgname.name; p_elttype CDATA #FIXED "orgname"
                         %orgname.attr.custom;
>

<!-- ###################################################################### -->

<!--
   The <version> element indicates version information.

   For example:

     <version date="Thu Jun 25 1998"
              time="18:10:25 CDT"
              revision="1.1 Beta"
              status="draft" />

   (auto-discovery of format? prefer ISO standard date formats?)
   (datetime in one field?)
 -->

<!ENTITY % version.name "version" >
<!ELEMENT %version.name; EMPTY>
<!ENTITY % version.attr.custom "" >
<!ENTITY % version.date.name "data" >
<!ATTLIST %version.name; p_elttype           CDATA #FIXED "version"
                         %version.date.name; CDATA #REQUIRED
                         time                CDATA #IMPLIED
                         revision            CDATA #IMPLIED
                         status              CDATA #IMPLIED
                         %version.attr.custom;
>

<!-- ###################################################################### -->

<!--
   The <copyright> element indicates a copyright notice.
   It may contain one or more links for additional information.
 -->
<!ENTITY % copyright.name "copyright" >
<!ENTITY % copyright.content "#PCDATA,&link.name;*" >
<!ENTITY % copyright.content.custom "" >
<!ELEMENT %copyright.name; (%copyright.content;
                            %copyright.content.custom;)>
<!ENTITY % copyright.attr.custom "" >
<!ATTLIST %copyright.name; p_elttype CDATA #FIXED "copyright"
                           %copyright.attr.custom;
>

<!-- ###################################################################### -->

]]> <!-- end conditional section for front matter -->


<!--
###############################################################################
#  PATTERN ELEMENTS                                                           #
###############################################################################
#  This section defines the elements that compose a pattern                   #
###############################################################################
 -->


<!--
  The <pattern> element wraps a pattern.
  It contains the standard pattern form elements, as well as some
  meta-information about the author and revision.

  (The idea of nesting patterns was suggested by J.D. Fagan, who conjuctures the
  existence of patterns that would not exist outside of the conext of another.
  I think the idea is a good one, but pattern references allow for the same
  structure.)
-->
<!ENTITY % pattern.name "pattern" >
<!ENTITY % pattern.content "%front.name;?,
                            %patname.name;,
                            %remark.name;*,
                            (%aka.name; | %keyword.name;)*,
                            %abstract.name;?,
                            %intent.name;?,
                            %context.name;,
                            %motivation.name;?,
                            %indications.name;?,
                            %applicablity.name;?,
                            %problem.name;,
                            %forces.name;?,
                            %solution.name;,
                            %consequences.name;?,
                            %rationale.name;?,
                            %discussion.name;?,
                            %implementation.name;?,
                            %example.name;?,
                            %knownUses.name;?,
                            %relatedPatterns.name;?,
                            %back.name;?"
>
<!ENTITY % pattern.content.custom "" >
<!ELEMENT %pattern.name; (%pattern.content;
                          %pattern.content.custom;)>
<!ENTITY % pattern.attr.custom "" >
<!ATTLIST %pattern.name; p_elttype CDATA #FIXED "pattern"
                         %pattern.attr.custom;
>

<!--
   The patsect.content.block entity simply declares the basic content model
   for a "block" pattern section.

   There can be at most one thumbnail description, and if present it must
   be the first child element.

   The remaining elements can be repeated multiple times, in any order.
 -->

<!ENTITY % patsect.content.block "#PCDATA
                                  | %programlisting.name;
                                  | %itemlist.name;
                                  | %generic.content.fontstyle.all;
                                  | %generic.content.refs.all;
                                  | %p.name;
                                  | %br.name;"
>

<!ENTITY % patsect.content.block.custom "">

<!ENTITY % patsect.content.block.all "%patsect.content.block;
                                      %patsect.content.block.custom;">

<!ENTITY % patsect.content.blockplus "(#PCDATA*, %thumbnail.name;?,
                                       (%patsect.content.block.all; | %remark.name; )*)"
>


<!--
   The <thumbnail> element represents a brief summary, suitable for using in an
   index or as a thumbnail description of the pattern.
 -->
<!ENTITY % thumbnail.name "thumbnail" >
<!ENTITY % thumbnail.content "(&generic.content.fontstyle.all; |
                               &generic.content.refs.all;)*" >
<!ENTITY % thumbnail.content.custom "" >
<!ELEMENT %thumbnail.name; (%thumbnail.content;
                            %thumbnail.content.custom;)>
<!ENTITY % thumbnail.attr.custom "" >
<!ATTLIST %thumbnail.name; p_elttype CDATA #FIXED "thumbnail"
                           %thumbnail.attr.custom;
>

<!--
   The <programlisting> element indicates explict source code, similar to
   the html <pre> element.

   The codelang attribute identifies the programing language used.
   (This might be useful if we want to do automated keyword coloring or
   other parsing/manipulation.)

   The caption attribute may be used to provide a title.

   Personally, I would prefer "code" as the name of this element,
   but I'm afraid this conflicts with the HTML code tag.

   Notes:
    · Should we enable xref to full source code listings?
 -->
<!ENTITY % programlisting.name "programlisting" >
<!ENTITY % programlisting.content "#PCDATA" >
<!ENTITY % programlisting.content.custom "" >
<!ELEMENT %programlisting.name; (%programlisting.content;
                                 %programlisting.content.custom;)>
<!ENTITY % programlisting.attr.custom "" >
<!ATTLIST %programlisting.name; p_elttype CDATA #FIXED "programlisting"
                                codelang  CDATA #IMPLIED
                                caption   CDATA #IMPLIED
                                %programlisting.attr.custom;
>

<!--
   The <patref> element represents a refernce to another pattern or subsection.
   It is composed of
     · a pattern name (or identifier?)
     · an optional sub-section of the pattern
     · zero or more relations that indicate how the other pattern relates
       to this one

   The relation attribute is used to indicate how the patterns relate.
   (see http://www.geocities.com/SiliconValley/Horizon/3829/xml.htm for
    examples of explict relations between patterns)

   Some examples: variant, collaborator

   The <patref> name was suggested by Brad Appleton, I originally had just
   <pat>.

   Notes:
    · should use some XLL structure?
 -->
<!ENTITY % patref.name "patref" >
<!ENTITY % patref.content "%patsect.content.inline;" >
<!ENTITY % patref.content.custom "" >
<!ELEMENT %patref.name; (%patref.content;
                         %patref.content.custom;)>
<!ENTITY % patref.attr.custom "" >
<!ENTITY % patref.pattern.name "pattern" >
<!ATTLIST %patref.name; p_elttype             CDATA #FIXED "patref"
                        %patref.pattern.name; CDATA #REQUIRED
                        section               CDATA #IMPLIED
                        relation              CDATA #IMPLIED
                        %patref.attr.custom;
>

<!--
   The <remark> element identifies a comment from the document author.
   Production renderings may choose not to display these remarks.

   The element indicates, in effect, an author's note to herself (or
   other authors).

   · perhaps we should add attributes for identifing the author who made
     the remark? or should we leave inside
   · this is likely to be an "inline" element, rather than a full "block"
     element.
 -->
<!ENTITY % remark.name "remark" >
<!ENTITY % remark.content "%patsect.content.block.all;" >
<!ENTITY % remark.content.custom "" >
<!ELEMENT %remark.name; (%remark.content;
                        %remark.content.custom;)>
<!ENTITY % remark.attr.custom "" >
<!ATTLIST %remark.name; p_elttype CDATA #FIXED "remark"
                        %remark.attr.custom;
>

<!--
   The <list> element groups a list of items (similar to <ol> and <ul>).

   The <item> element represents an item in a list (similar to the html <li>).

   Notes:
     · I suggest <item> rather than an html list, since we may choose to
       represent the enumerated items in a different format
       (Should we use html notation anyway? We can always display/use it
        however we want).

     · Despite being my personal preference, the <item> name is probably
       a bad choice?

     · Perhaps <enum> instead of <itemlist>?

     · Attributes of itemlist similiar to ol, ul, etc.?

 -->
<!ENTITY % list.name "list" >
<!ENTITY % list.content.custom "" >
<!ELEMENT %list.name; (item+
                        %list.content.custom;)>
<!ENTITY % list.attr.custom "" >
<!ATTLIST %list.name; p_elttype CDATA #FIXED "list"
                      %list.attr.custom;
>

<!ENTITY % item.name "item" >
<!ENTITY % item.content "%patsect.content.blockplus;" >
<!ENTITY % item.content.custom "" >
<!ELEMENT %item.name; (%item.content;
                       %item.content.custom;)>
<!ENTITY % item.attr.custom "" >
<!ATTLIST %item.name; p_elttype CDATA #FIXED "item"
                      %item.attr.custom;
>

<!--
   The <patname> element indicates the name of the pattern.

   Perhaps this should just be an attribute of the pattern tag?
 -->
<!ELEMENT patname (#PCDATA)>

<!--
   The <aka> element indicates the other names for the pattern.
   Note that exactly one alias is listed per element, multiple elements
   may be used.

   Notes:
    · Add attributes for referencing where the alias is used?
    · This cannot be an attribue of pattern, since we want to allow more than
      aka.
    · Perhaps this should be an empty tag with an attribute?
      E.g.
      <aka content="Another Other Name for this Pattern" />
      This might help reinforce that this is a value, rather than markup.
      Also, this tag does not have the same content model as other sections.
 -->
<!ELEMENT aka (#PCDATA)>

<!--
   The <keyword> element indicates a key word or phrase that may be useful in
   catagorizing the pattern.
   Note that exactly one word or phrase is listed per element,
   multiple elements may be used to indicate multiple keywords.

   Perhaps keyword should be an empty tag, similiar to the HTML meta type?
   E.g.:
     <keyword content="The Key Word or Phrase" />
   This might help reinforce that this is a value, rather than markup.

   If we go that far, isn't "keywords" better, just like the HTML meta:
     <keyword content="KeyWordA,KeyWordB,Key Phrase" />

   The 'one keyphrase per tag' form is probably easier to parse.
 -->
<!ELEMENT keyword (#PCDATA)>


<!--
   The <abstract> element indicates a summary suitable for extracting to a summary
   or table of contents.
 -->
<!ELEMENT abstract (%patsect.content.blockplus;)>

<!--
   The <intent> element indicates the intent section
   (what the pattern hopes to achieve)
 -->
<!ELEMENT intent (%patsect.content.blockplus;)>

<!--
   The <context> element indicates the context section
   (when/where the pattern is applicable)
 -->
<!ELEMENT context (%patsect.content.blockplus;)>

<!--
   The <motivation> element indicates the motivation section
   (a narrative description of when the pattern might arise)
 -->
<!ELEMENT motiviation (%patsect.content.blockplus;)>

<!--
   The <indications> element indicates the indications section
   (similar to <context>, when might the pattern be applied)
   a synonym is "symptoms"
 -->
<!ELEMENT indications (%patsect.content.blockplus;)>

<!--
   The <applicablity> element indicates the applicablity section
   (another variation on <indications> and <context>)
 -->
<!ELEMENT applicablity (%patsect.content.blockplus;)>

<!--
   The <problem> element indicates the problem section
   (an explict statement of the problem)
 -->
<!ELEMENT problem (%patsect.content.blockplus;)>

<!--
   The <forces> element indicates the forces section
   (forces involved in the problem/solution)
 -->
<!ELEMENT forces (%patsect.content.blockplus;)>

<!--
   The <solution> element indicates the solution section
   (the proposed solution to the problem)
 -->
<!ELEMENT solution (%patsect.content.blockplus;)>

<!--
   The <consequences> element indicates the consequences section
   (the results of applying the solution to the problem)
 -->
<!ELEMENT consequences (%patsect.content.blockplus;)>

<!--
   The <rationale> element indicates the rationale section
   (why the solution is a good choice)

   Notes:
   · too similar to consequences or discussion?
 -->
<!ELEMENT rationale (%patsect.content.blockplus;)>

<!--
   The <discussion> element indicates the discussion section.
   (commentary on how the solution resolves the forces)

   Notes:
   · too similar to consequences or rationale?
   · any votes for <analysis>?
 -->
<!ELEMENT discussion (%patsect.content.blockplus;)>

<!--
   The <implementation> element indicates the implementation section.
   (to me, this is a synonym for examples or sampleCode, but in GOF,
    pitfalls, hints or techniques you should be aware of when implementing
    the pattern)
 -->
<!ELEMENT implementation (%patsect.content.blockplus;)>

<!--
   The <example> element indicates the example section.

   Notes:
   · see <implementation>
 -->
<!ELEMENT example (%patsect.content.blockplus;)>

<!--
   The <knownUses> element indicates the known uses section.
   (specific cases in which this pattern has been sucessfully applied)

   Notes:
   · do we need greater structure here?
 -->
<!ELEMENT knownUses (%patsect.content.blockplus;)>

<!--
   The <relatedPatterns> element indicates the related patterns section.
   (similiar or related patterns)

   Notes:
    · relation to see also?
 -->
<!ELEMENT relatedPatterns (%patsect.content.blockplus;)>


Rev. 0.3 beta 6 July 1998
Rod Waldhoff
rod@pg.net · rwald@hotmail.com
My root Tripod page:
members.tripod.com/~rwald

Valid Netscape-HTML!