[Docstring-checkins] CVS: dps/spec doctree.txt,1.8,1.9

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Update of /cvsroot/docstring/dps/spec
In directory usw-pr-cvs1:/tmp/cvs-serv15599/dps/spec

Modified Files:
	doctree.txt 
Log Message:
fixed whitespace

Index: doctree.txt
===================================================================
RCS file: /cvsroot/docstring/dps/spec/doctree.txt,v
retrieving revision 1.8
retrieving revision 1.9
diff -C2 -d -r1.8 -r1.9
*** doctree.txt	16 Mar 2002 06:11:11 -0000	1.8
--- doctree.txt	18 Apr 2002 02:53:21 -0000	1.9
***************
*** 8,23 ****

  This document describes the internal data structure representing
! document trees in the Python Docstring Processing System. The data
  structure is defined by the hierarchy of classes in the ``dps.nodes``
! module. It is also formally described by the `Generic Plaintext
  Document Interface DTD`_ XML document type definition, gpdi.dtd_,
  which is the definitive source for element hierarchy details.

  Below is a simplified diagram of the hierarchy of element types in the
! DPS document tree structure. An element may contain any other elements
! immediately below it in the diagram. Note text is in square brackets.
! Element types in parentheses indicate recursive or one-to-many
! relationships; sections may contain (sub)sections, tables contain
! further body elements, etc. ::

    +--------------------------------------------------------------------+
--- 8,23 ----

  This document describes the internal data structure representing
! document trees in the Python Docstring Processing System.  The data
  structure is defined by the hierarchy of classes in the ``dps.nodes``
! module.  It is also formally described by the `Generic Plaintext
  Document Interface DTD`_ XML document type definition, gpdi.dtd_,
  which is the definitive source for element hierarchy details.

  Below is a simplified diagram of the hierarchy of element types in the
! DPS document tree structure.  An element may contain any other
! elements immediately below it in the diagram.  Note text is in square
! brackets.  Element types in parentheses indicate recursive or
! one-to-many relationships; sections may contain (sub)sections, tables
! contain further body elements, etc. ::

    +--------------------------------------------------------------------+
***************
*** 43,49 ****

  A class hierarchy has been implemented in nodes.py where the position
! of the element (the level at which it can occur) is significant. E.G.,
! Root, Structural, Body, Inline classes etc. Certain transformations
! will be easier because we can use isinstance() on them.

  The elements making up DPS document trees can be categorized into the
--- 43,50 ----

  A class hierarchy has been implemented in nodes.py where the position
! of the element (the level at which it can occur) is significant.
! E.G., Root, Structural, Body, Inline classes etc.  Certain
! transformations will be easier because we can use isinstance() on
! them.

  The elements making up DPS document trees can be categorized into the
***************
*** 201,205 ****
  ================
  The ``%basic.atts;`` parameter entity lists attributes common to all
! elements. See `Common Attributes`_.

--- 202,206 ----
  ================
  The ``%basic.atts;`` parameter entity lists attributes common to all
! elements.  See `Common Attributes`_.

***************
*** 238,242 ****
  Having added the "horizontal rule" construct to the reStructuredText_
  spec, a decision had to be made as to how to reflect the construct in
! the implementation of the document tree. Given this source::

      Document
--- 239,243 ----
  Having added the "horizontal rule" construct to the reStructuredText_
  spec, a decision had to be made as to how to reflect the construct in
! the implementation of the document tree.  Given this source::

      Document
***************
*** 250,254 ****

  The horizontal rule indicates a "transition" (in prose terms) or the
! start of a new "division". Before implementation, the parsed document
  tree would be::

--- 251,255 ----

  The horizontal rule indicates a "transition" (in prose terms) or the
! start of a new "division".  Before implementation, the parsed document
  tree would be::

***************
*** 263,272 ****
                  Paragraph

! There are several possibilities for the implementation. Solution 3
  was chosen.

! 1. Implement horizontal rules as "divisions" or segments. A "division"
!    is a title-less, non-hierarchical section. The first try at an
!    implementation looked like this::

         <document>
--- 264,273 ----
                  Paragraph

! There are several possibilities for the implementation.  Solution 3
  was chosen.

! 1. Implement horizontal rules as "divisions" or segments.  A
!    "division" is a title-less, non-hierarchical section.  The first
!    try at an implementation looked like this::

         <document>
***************
*** 281,287 ****

     But the two paragraphs are really at the same level; they shouldn't
!    appear to be at different levels. There's really an invisible
!    "first division". The horizontal rule splits the document body into
!    two segments, which should be treated uniformly.

  2. Treating "divisions" uniformly brings us to the second
--- 282,288 ----

     But the two paragraphs are really at the same level; they shouldn't
!    appear to be at different levels.  There's really an invisible
!    "first division".  The horizontal rule splits the document body
!    into two segments, which should be treated uniformly.

  2. Treating "divisions" uniformly brings us to the second
***************
*** 300,308 ****

     With this change, documents and sections will directly contain
!    divisions and sections, but not body elements. Only divisions will
!    directly contain body elements. Even without a horizontal rule
     anywhere, the body elements of a document or section would be
!    contained within a division element. This makes the document tree
!    deeper. This is similar to the way HTML treats document contents:
     grouped within a <BODY> element.

--- 301,309 ----

     With this change, documents and sections will directly contain
!    divisions and sections, but not body elements.  Only divisions will
!    directly contain body elements.  Even without a horizontal rule
     anywhere, the body elements of a document or section would be
!    contained within a division element.  This makes the document tree
!    deeper.  This is similar to the way HTML treats document contents:
     grouped within a <BODY> element.

***************
*** 320,326 ****

     A transition would be a "point element", not containing anything,
!    only identifying a point within the document structure. This keeps
     the document tree flatter, but the idea of a "point element" like
!    "transition" smells bad. A transition isn't a thing itself, it's
     the space between two divisions.

--- 321,327 ----

     A transition would be a "point element", not containing anything,
!    only identifying a point within the document structure.  This keeps
     the document tree flatter, but the idea of a "point element" like
!    "transition" smells bad.  A transition isn't a thing itself, it's
     the space between two divisions.