<!-- $Id: p2fd.odd,v 1.13 1998/02/01 16:18:53 tei Exp $ -->
<!--*
    * $Log: p2fd.odd,v $
    * Revision 1.13  1998/02/01 16:18:53  tei
    * change system to public identifier (again)
    *
    * Revision 1.12  1998/01/31 19:14:05  tei
    * Use public identifiers, not system identifiers.
    *
    * Revision 1.11  1998/01/31 18:27:01  tei
    * fix log keyword
    *
    * Revision 1.10  94/04/08  18:54:36  msmcq
    * Last-second fixes for P3
    *
    * Revision 1.9  1994/04/07  23:57:46  msmcq
    * revision while validating dtd
    *
    * Revision 1.8  1994/04/01  16:23:58  msmcq
    * Misc. changes/fixes while validating DTDs
    *
    * Revision 1.7  1994/03/28  17:31:16  msmcq
    * changes to dtdfrags
    *
    * Revision 1.6  1994/03/27  21:48:09  msmcq
    * Correction of typos found by WWP, DB
    *-->
<!-- Revisions:                                               -->
<!-- 94-04-08 : MSM : correct tagging slip                    -->
<!-- 94-04-07 : MSM : embed teifs2.dtd                        -->
<!-- 94-04-07 : MSM : suppress duplicate declaration of THEN  -->
<!-- 94-04-07 : MSM : create better overall dtdfrag           -->
<!-- 94-03-29 : MSM : add fsDescr to a dtdfrag                -->
<!-- 94-03-28 : MSM : add file info to dtdfrags               -->
<!-- 94-03-27 : MSM : typos from EM, DB                       -->
<!-- 93-05-31 : MSM : recast two footnotes                    -->
<!-- 93-05-23 : GS  : revisions following Eynsham review      -->
<!-- 93-04-09 : MSM : complete update                         -->
<!-- 1993-04-09 : MSM : complete about half of GS's updates   -->
<!-- 1993-04-08 : MSM : tag as an Odd, make tagdocs           -->
<!-- From: gary@sil.org (Gary Simons)                         -->
<!-- X-Mailer: SCO System V Mail (version 3.2)                -->
<!-- To: u35395@uicvm.uic.edu                                 -->
<!-- Subject: Draft of FSD chapter                            -->
<!-- Date: Wed, 1 Jul 92 7:13:38 CDT                          -->

<div1 id="FD" n="26"><head>Feature System Declaration</head>

<p>The Feature System Declaration (FSD) is an auxiliary file used in
conjunction with a TEI-conforming text that makes use of <gi>fs</gi>
(that is, feature structure) elements.

<!-- <note place=foot><p>The primary responsibility for this -->
<!-- chapter was borne by work group AI 1, for linguisticstudy, -->
<!-- whose members are listed in the front matter.  It was -->
<!-- drafted by Gary F.  Simons.</p></note>  -->

The FSD serves three purposes:

<list>

<item>It provides a mechanism by which the encoder can list all of the
feature names and feature values and give a prose description as to what
each represents.</item>

<item>It provides a mechanism by which the encoder can define
constraints on what it means to be a well-formed feature structure.
These constraints may involve constraints on the range of a feature
value, constraints on what features are valid within certain types of
feature structures, or constraints that prevent the co-occurrence of
certain feature-value pairs.</item>

<item>It provides a mechanism by which the encoder can define the
intended interpretation of underspecified feature structures.  This
involves defining default values (whether literal or computed) for
missing features.</item>

</list></p>

<p>As a component of the interchange standard for encoded text, the FSD
serves an important function in documenting precisely what the encoder
intended by the system of feature structure markup used in the encoded
text.  As application software is developed which makes use of encoded
texts, the FSD will also become an important resource that will allow
software to validate the feature structure markup in a text and to infer
the full interpretation of underspecified feature structures.</p>

<p>This chapter begins by describing how the encoded text uses header
information to make links to any associated FSDs.  The second through
fourth sections describe the overall structure of an FSD and give
details of how to encode its parts.  The final section offers a full
example.
<note place="foot">For a fuller discussion of the reasoning behind FSDs
and for another complete example, see <q>A rationale for the TEI
recommendations for feature-structure markup,</q> by D. Terence
Langendoen and Gary F. Simons (to appear in the special TEI issue of
<title>Computers and the Humanities</title>).</note></p>

<div2 id="FDlk"><head>Linking a TEI Text to Feature System Declarations</head>

<p>In order for application software to use feature system declarations
to aid in the automatic interpretation of encoded texts, or even for
human readers to find the appropriate declarations which document the
feature system used in markup, there must be a formal link from the
encoded texts to the declarations.  As it turns out, the mechanism for
linking texts to FSDs parallels the mechanism for linking texts to
writing system declarations (WSDs).

<!-- described in chapter <ptr target=WD>,--></p>

<p>The linkage is made in two places.  First, in the DTD subset of the
document type declaration at the beginning of the text file, an external
entity is defined for each FSD that is associated with the encoded text.
That entity declaration associates an entity name with the name of a
file on the host system.  It appends the SUBDOC keyword to tell the
processor that the named file is a self-contained SGML document.  See
the example below for details of syntax.</p>

<p>The second place in which the linkage from text to FSDs is made is in
the TEI header, as mentioned in section <ptr target="HDfsd">.  Within the
<gi>encodingDesc</gi> element, a special <gi>fsdDecl</gi> element may be
used for each distinct feature structure type, as follows:

<list type=gloss>
<label><gi>fsdDecl</gi></label>
<item>identifies the feature system declaration which contains

definitions for a particular type of feature structure.
Attributes include:
<list type=gloss>
<label><att>type</att></label>
<item>identifies the type of feature structure documented in the 
FSD; this will be the value of the <att>type</att> 
attribute on at least one feature structure.</item>
<label><att>fsd</att></label>
<item>specifies the external entity containing the feature system 
declaration; an entity declaration in the document's DTD 
subset must associate the entity name with a file on the 
system.</item>
</list>
</item>
</list>


Note that one <gi>fsdDecl</gi> element must be specified for each
distinct type of feature structure used in the markup.  The
<att>fsd</att> element supplies the name of the external entity
containing the actual declaration for that type of feature structure.</p>

<p>There may be multiple <gi>fsdDecl</gi> elements for a given FSD; one
for each type of feature structure it defines.  For instance, in the
following example, the file <ident rend="noindex" type="file">lex.fsd</ident> contains an FSD that contains definitions
of feature structures for both lexical entries (<tag>fs
type=entry</tag>) and lexical subentries (<tag>fs type=subentry</tag>).</p>

<p>The following example shows the markup for linking a TEI document to
two WSDs and two FSDs.  The linkage to both WSDs and FSDs is shown in
order to illustrate the parallel nature of the linking mechanisms for
both kinds of auxiliary files.

<eg>
<![ CDATA [
   <!DOCTYPE tei.2 PUBLIC "-//TEI P3//DTD Main Document Type//EN"
                          "tei2.dtd" [
      <!-- In the DTD subset, we declare external
           entities for our FSDs and WSDs.        -->
      <!ENTITY wsd.english system 'en.wsd'   SUBDOC >
      <!ENTITY wsd.french  system 'fr.wsd'   SUBDOC >
      <!ENTITY fsd.gazdar  system 'gpsg.fsd' SUBDOC >
      <!ENTITY fsd.lexicon system 'lex.fsd'  SUBDOC >
   ]>
   <tei.2>

   <teiHeader>
      <!-- In the encoding description of the TEI header,
           we link the FSDs to the fs TYPE attribute;
           in the profile description,
           we link the WSDs to the global LANG attribute.
           -->
      <fileDesc> ... </fileDesc>
      <encodingDesc>
           <!-- ... -->
           <fsdDecl type=GPSG     fsd=fsd.gazdar>
           <fsdDecl type=entry    fsd=fsd.lexicon>
           <fsdDecl type=subentry fsd=fsd.lexicon>
           <!-- ... -->
      </encodingDesc>
      <profileDesc>
           <!-- ... -->
           <langUsage>
               <language id=EN wsd=wsd.english>English</>
               <language id=FR wsd=wsd.french >French</>
           </langUsage>
      </profileDesc>
   </teiHeader>
   <!-- The text goes here -->
   </TEI.2>
]]>
</eg></p>

<p>The auxiliary tag set for feature system declarations is contained
in the file <ident type="file">teifsd2.dtd</ident>, which has the
public identifier <code>-//TEI P3//DTD Auxiliary Document Type:
Feature System Declaration//EN</code> and the overall structure shown
below:

<eg id=dfddtd>
<![ CDATA [
<!-- 26.1:  Feature System Declaration                        -->
<!-- Text Encoding Initiative: Guidelines for Electronic      -->
<!-- Text Encoding and Interchange. Document TEI P3, 1994.    -->

<!-- Copyright (c) 1994 ACH, ACL, ALLC. Permission to copy    -->
<!-- in any form is granted, provided this notice is          -->
<!-- included in all copies.                                  -->

<!-- These materials may not be altered; modifications to     -->
<!-- these DTDs should be performed as specified in the       -->
<!-- Guidelines in chapter "Modifying the TEI DTD."           -->

<!-- These materials subject to revision. Current versions    -->
<!-- are available from the Text Encoding Initiative.         -->
<!-- First, we declare basic parameter entities and embed     -->
<!-- auxiliary files.                                         -->

<!-- Embed entities for TEI generic identifiers.              -->

<!ENTITY % TEI.elementNames system 'teigis2.ent'                >
%TEI.elementNames;

<!-- Embed entities for TEI keywords.                         -->

<!ENTITY % TEI.keywords.ent system 'teikey2.ent'                >
%TEI.keywords.ent;

<!-- Define element classes for content models, shared        -->
<!-- attributes for element classes, and global attributes.   -->
<!-- (This all happens within the file teiclas2.ent.)         -->

<!ENTITY % TEI.elementClasses system 'teiclas2.ent'             >
%TEI.elementClasses;

<!-- Define element classes for feature structure             -->
<!-- declarations.                                            -->

<!ENTITY % x.boolean ''                                         >
<!ENTITY % m.boolean '%x.boolean any | none'                    >
<!ENTITY % x.binary ''                                          >
<!ENTITY % m.binary '%x.binary minus | plus'                    >
<!ENTITY % x.singleVal ''                                       >
<!ENTITY % m.singleVal '%x.singleVal %m.binary; | %m.boolean; | 
           dft | msr | nbr | rate | str | sym | uncertain'      >
<!ENTITY % x.complexVal ''                                      >
<!ENTITY % m.complexVal '%x.complexVal alt | fs | vAlt'         >
<!ENTITY % x.featureVal ''                                      >
<!ENTITY % m.featureVal '%x.featureVal %m.complexVal; | 
           %m.singleVal; | null'                                >

<!-- Now, we declare the elements for FSDs proper.            -->

<!-- ... declarations from section 26.2                       -->
<!--     (Feature System Declaration)                         -->
<!--     go here ...                                          -->
<!-- ... declarations from section 26.3                       -->
<!--     (Feature definitions)                                -->
<!--     go here ...                                          -->
<!-- ... declarations from section 26.4                       -->
<!--     (Feature structure constraints)                      -->
<!--     go here ...                                          -->

<!-- The elements for feature structures themselves are       -->
<!-- declared in teifs2.dtd                                   -->

<!ENTITY % TEI.fs.dtd system 'teifs2.dtd'                       >
%TEI.fs.dtd;

<!-- Finally, embed the TEI header and core tag sets.         -->

<!ENTITY % TEI.header.dtd system 'teihdr2.dtd'                  >
%TEI.header.dtd;
<!ENTITY % TEI.core.dtd system 'teicore2.dtd'                   >
%TEI.core.dtd;
]]>
</eg>
</p></div2>

<div2 id="FDov"><head>The Overall Structure of a Feature System Declaration</head>

<p>A feature system declaration is encoded as a document of type
<gi>teiFsd2</gi>.  It has two parts:  an obligatory header (which
provides bibliographic information for the file) and a set of feature
structure declarations (each of which defines one type of feature
structure).  Each feature structure declaration in turn has three parts:
an optional description (which gives a prose comment on what that type
of feature structure encodes), an obligatory set of feature declarations
(which specify range constraints and default values for the features in
that type of structure), and optional feature structure constraints
(which specify co-occurrence restrictions on feature values).  The
header is encoded as a <gi>teiHeader</gi>, just as for any TEI.2
document; see chapter <ptr target="HD">.  The other components listed
above are unique to feature system declarations.  Thus, the following
new elements are involved:

<list type=gloss>
<label><gi>teiFsd2</gi></label>
<item>contains a feature system declaration.</item>
<label><gi>fsDecl</gi></label>
<item>declares one type of feature structure.
Attributes include:
<list type=gloss>
<label><att>type</att></label>
<item>gives a name for the type of feature structure being 
declared.</item>
<label><att>baseType</att></label>
<item>gives the name of the feature structure type from which 
this type inherits features and constraints; if this type 
declares a feature with the same name as a feature of the 
base type, the definition within this <gi>fsDecl</gi> 
overrides the inherited definition. The 
<gi>fsConstraints</gi> are inherited only if this 
<gi>fsDecl</gi> does not specify any; otherwise the 
constraints in this <gi>fsDecl</gi> override. When no 
<att>baseType</att> is specified, no features or 
constraints are inherited.</item>
</list>
</item>
<label><gi>fsDescr</gi></label>
<item>describes in prose what is represented by the type of 
feature
structure declared in the enclosing 
<gi>fsDecl</gi>.</item>
<label><gi>fDecl</gi></label>
<item>declares a single feature, specifying its name, 
organization,
range of allowed values, and optionally its 
default value.</item>
<label><gi>fsConstraints</gi></label>
<item>specifies constraints on the content of well formed feature
structures.</item>
</list>
</p>

<p>Feature declarations and feature structure constraints are described
in the next two sections of this chapter.  Note that the specification
of similar <gi>fsDecl</gi> elements can be simplified by devising an
inheritance hierarchy for the feature structure types.  Each
<gi>fsDecl</gi> may name a <att>baseType</att> from which it inherits
feature declarations and constraints.  For instance, suppose that
<tag>fsDecl type=Basic</tag> contains <tag>fDecl name=One</tag> and
<tag>fDecl name=Two</tag>, and that <tag>fsDecl type=Derived
baseType=Basic</tag> contains just <tag>fDecl name=Three</tag>.  Then
any instance of <tag>fs type=Derived</tag> may include all three
features.  This is because <tag>fsDecl type=Derived</tag> inherits the
two feature declarations from <tag>fsDecl type=Basic</tag> when it
specifies a <att>baseType</att> of <code type="value">Basic</code>.</p>

<p>The following sample shows the overall structure of a complete FSD.
Note that as a stand-alone document it begins with a DOCTYPE declaration
which identifies the associated DTD.


<eg>
<![ CDATA [
  <!DOCTYPE teiFsd2 PUBLIC "-//TEI P3//DTD Auxiliary Document Type:
        Feature System Declaration//EN"
       "teifsd2.dtd" >
  <teiFsd2>
     <teiHeader>
        <!-- The header is as for any TEI.2 document -->
     </teiHeader>
     <fsDecl type=SomeName>
        <fsDescr>Describes what this type of fs represents</>
        <fDecl name=featureOne>
           <!-- The declaration for featureOne -->
        </fDecl>
        <fDecl name=featureTwo>
           <!-- The declaration for featureTwo -->
        </fDecl>
        <fsConstraints>
           <!-- The feature structure constraints go here -->
        </fsConstraints>
     </fsDecl>
     <fsDecl type=AnotherType>
           <!-- Declare another type of feature structure -->
     </fsDecl>
  </teiFsd2>
]]>
</eg></p>


<p>The formal definition of <gi>teiFsd2</gi> and feature structure
declarations is as follows:

<eg id=dfdfsd2>
<![ CDATA [
<!-- 26.2:  Feature System Declaration                        -->
<!ELEMENT teiFsd2       - -  (teiHeader, fsDecl+)               >
<!ATTLIST teiFsd2            %a.global;                         >
<!ELEMENT fsDecl        - -  (fsDescr?, fDecl+, fsConstraints?) 
                                                                >
<!ATTLIST fsDecl             %a.global;
          baseType           CDATA               #IMPLIED
          type               CDATA               #REQUIRED      >
<!ELEMENT fsDescr       - O  (%paraContent;)                    >
<!ATTLIST fsDescr            %a.global;                         >
<!-- This fragment is used in sec. 26.1                       -->
]]>
</eg>
</p></div2>

<div2 id="FDfd"><head>Feature Declarations</head>

<p>Each feature is declared in an <gi>fDecl</gi> element whose
<att>name</att> attribute identifies the feature being declared; this
matches the <att>name</att> attribute of the <gi>f</gi> elements it
declares.  An <gi>fDecl</gi> also has an <att>org</att> attribute which
declares the organizing principle for the values of the <gi>f</gi>
elements it declares.  That is, the value may be a <code type="value">unit</code> (a single value), a <code type="value">set</code>
(in which the order is not significant and there are no duplicates), a
<code type="value">bag</code> (in which the order is not significant but
duplicates are allowed), or a <code type="value">list</code> (in which the
order is significant).  (See definition of <att>org</att> attribute of
<gi>f</gi> in section <ptr target="FSss">.)  An <gi>fDecl</gi> has three
parts:  an optional prose description (which should explain what the
feature and its values represent), an obligatory range specification
(which declares what values the feature is allowed to have), and an
optional default specification (which declares what default value should
be supplied when the named feature does not appear in an <gi>fs</gi>).
A single unconditional default value may be specified, or multiple
conditional values.  If no default is specified, or if none of the
conditions is met, then the default value is <gi>none</gi>; in other
words, the feature is not applicable (see section <ptr target="FSbo"> for
a discussion of the <gi>none</gi> element).</p>

<p>The tags used in feature declarations are the following:

<list type=gloss>
<label><gi>fDecl</gi></label>
<item>declares a single feature, specifying its name, 
organization,
range of allowed values, and optionally its 
default value.
Attributes include:
<list type=gloss>
<label><att>name</att></label>
<item>indicates the name of the feature being declared; matches 
the <att>name</att> attribute of <gi>f</gi> elements in the 
text.</item>
<label><att>org</att></label>
<item>specifies the organizing discipline of the feature value.
Legal values are:
<list type=gloss>
<label><term>set</term></label>
<item>set value (unordered, no duplicates)</item>
<label><term>list</term></label>
<item>list value (ordered, may have duplicates)</item>
<label><term>bag</term></label>
<item>bag value (unordered, may have duplicates)</item>
<label><term>unit</term></label>
<item>unitary atomic value</item>
</list></item>
</list>
</item>
<label><gi>fDescr</gi></label>
<item>describes in prose what is represented by the feature being
declared and its values.</item>
<label><gi>vRange</gi></label>
<item>defines the range of allowed values for a feature, in the 
form of
an <gi>fs</gi>, <gi>vAlt</gi>, or primitive value;
for the value of an <gi>f</gi> to be valid, it must be

<term>subsumed</term> by the specified range; if the 
<gi>f</gi>
contains multiple values (as sanctioned by the 
<att>org</att> attribute),
then each value must be 
subsumed by the <gi>vRange</gi>.</item>
<label><gi>vDefault</gi></label>
<item>declares the default value to be supplied when a feature 
structure
does not contain an instance of <gi>f</gi> for 
this name; if
unconditional, it is specified as one (or, 
depending on the value of
the <att>org</att> attribute of 
the enclosing <gi>fDecl</gi>) more
<gi>fs</gi> elements or 
primitive values;
if conditional, it is specified as
one 
or more <gi>if</gi> elements; if no default is specified, 
or no
condition matches, the value <gi>none</gi> is 
assumed.</item>
<label><gi>if</gi></label>
<item>defines a conditional default value for a feature; the 
condition
is specified as a feature structure, and is met 
if it
<term>subsumes</term> the feature structure in the 
text for which a
default value is sought.</item>
<label><gi>then</gi></label>
<item>separates the condition from the default in an <gi>if</gi>, 
or
the antecedent and the consequent in a <gi>cond</gi> 
element.</item>
</list>
</p>

<p>The logic for validating feature values and for matching the
conditions for supplying default values is based on the operation of
subsumption.  Subsumption is a standard operation in
feature-structure-based formalisms.  Informally, a feature structure
<emph>fs</emph> subsumes all feature structures that are at least as
informative as itself; that is, all feature structures that specify at
least as many features as <emph>fs</emph> with values at least as
informative as those given in <emph>fs</emph> (Pereira 1987:6; see also
Shieber 1986:14-16).
<note place="foot"><bibl>
Fernando C. N. Pereira, <title>Grammars and logics of partial
information</title>, SRI International Technical Note 420 (Menlo
Park, CA: SRI International, 1987)</bibl>, and
<bibl>
Stuart Shieber, <title>An Introduction to Unification-based
Approaches to Grammar</title>, CSLI Lecture Notes 4 (Palo Alto,
CA: Center for the Study of Language and Information,
1986).</bibl>
</note>
A more formal definition requires that we first define the notion of
<q>domain of a feature structure.</q> A feature structure can be viewed
as a partial function that maps features onto values; when viewed in
this way, the domain of a feature structure is the set of top-level
features it contains (that is, excluding features in embedded feature
structures).  We can now offer a more precise definition:

<q rend="display">
     <emph>fs</emph> subsumes <emph>fs&prime;</emph> if both are
     identical primitive values, or if the domain of <emph>fs</emph>
     is a subset of the domain of <emph>fs&prime;</emph>, and for every
     feature <emph>f</emph> in the domain of <emph>fs</emph>, the
     value of <emph>f</emph> in <emph>fs</emph> subsumes the value
     of <emph>f</emph> in <emph>fs'</emph>.
</q></p>

<p>Following the spirit of the informal definition above, we can extend
subsumption in a straightforward way to cover alternation, negation,
special primitive values, and the use of attributes in the SGML markup.
For instance, a <gi>vAlt</gi> containing the value <code type="value">v</code> subsumes <code type="value">v</code>.  The negation
<code type="frag">REL=ne</code> of value <code type="value">v</code>
subsumes any value that is not <code type="value">v</code>.  The value
<gi>unknown</gi> subsumes any value.  The value <gi>any</gi> subsumes
any value that is in the range of a feature.  <tag>fs
type=X</tag><tag>/fs</tag> subsumes any feature structure with TYPE=X.
<tag>nbr rel=ge value=0</tag> subsumes any <gi>nbr</gi> with value
greater than or equal to zero.</p>

<p>As an example of feature declarations, consider the following extract
from <title>Generalized Phrase Structure Grammar</title> by Gerald
Gazdar, Ewan Klein, Geoffrey Pullum, and Ivan Sag (Harvard University
Press, 1985).  In the appendix to their book (pages 245-247), they
propose a feature system for English of which this is just a sampling:

<eg>
   feature    value range

   INV        {+, -}
   CONJ       {and, both, but, either, neither, nor, or, NIL}
   COMP       {for, that, whether, if, NIL}
   AGR        CAT
   PFORM      {to, by, for, ...}
</eg>
<eg>
   Feature specification defaults

   FSD 1:  [-INV]
   FSD 2:  ~[CONJ]
   FSD 9:  [INF, +SUBJ] --> [COMP for]
</eg></p>

<p>The INV feature, which encodes whether or not a sentence is inverted,
allows only the values plus (+) and minus (-).  If the feature is not
specified, then the default rule (FSD 1 above) says that a value of
minus is always assumed.  The feature declaration for this feature would
be encoded as follows:

<eg>
<![ CDATA [
        <fDecl name=INV>
           <fDescr>inverted sentence</fDescr>
           <vRange>
               <vAlt><plus><minus></vAlt></vRange>
           <vDefault>
               <minus></vDefault>
        </fDecl>
]]>
</eg></p>

<p>The value range is specified as an alternation (more precisely, an
exclusive disjunction) of <gi>plus</gi> and <gi>minus</gi>.  That is,
the value must be one or the other, but not both or neither.</p>

<p>The CONJ feature indicates the surface form of the conjunction used
in a construction.  The ~ in the default rule (see FSD 2 above)
represents negation.  This means that by default the feature is not
applicable, in other words, no conjunction is taking place.  This
corresponds to the simple value <gi>none</gi>; see section <ptr
target="FSbo">.  Note that this is distinct from the NIL value allowed in
the value range.  In their analysis, NIL means that the phenomenon of
conjunction is taking place but there is no explicit conjunction in the
surface form of the sentence.  The feature declaration for this feature
would be encoded as follows:

<eg>
<![ CDATA [
<fDecl name=CONJ>
   <fDescr>surface form of the conjunction</fDescr>
   <vRange>
      <vAlt>
         <sym value=and>
         <sym value=both>
         <sym value=but>
         <sym value=either>
         <sym value=neither>
         <sym value=nor>
         <sym value=or>
         <sym value=NIL>
      </vAlt></vRange>
   <vDefault>
      <none></vDefault>
</fDecl>
]]>
</eg>

Note that the <gi>vDefault</gi> is not strictly necessary in this case,
since <gi>none</gi> is the value assumed in the absence of a default
specification.</p>

<p>The COMP feature indicates the surface form of the complementizer
used in a construction.  In value range, it is analogous to CONJ.
However, its default rule (see FSD 9 above) is conditional.  It says
that if the verb form is infinitival (the VFORM feature is not mentioned
in the rule since it is the only feature that can take INF as a value),
and the construction has a subject, then a <mentioned>for</mentioned> complement
must be used.  For instance, to make John the subject of the infinitive
in <mentioned>It is necessary to go,</mentioned> a <mentioned>for</mentioned> complement
must be used; that is, <mentioned>It is necessary for John to go.</mentioned>
The feature declaration for this feature would be encoded as follows:

<eg>
<![ CDATA [
<fDecl name=COMP>
   <fDescr>surface form of the complementizer</fDescr>
   <vRange>
      <vAlt>
         <sym value=for>
         <sym value=that>
         <sym value=whether>
         <sym value=if>
         <sym value=NIL>
      </vAlt></vRange>
   <vDefault>
      <if><fs><f name=VFORM><sym value=INF></f>
              <f name=SUBJ><plus></f></fs>
      <then><sym value=for></if>
      </vDefault>
</fDecl>
]]>
</eg></p>

<p>The AGR feature stores the features relevant to subject-verb
agreement.  Gazdar et al. specify the range of this feature as CAT.
This means that the value is a <term rend="noindex">category</term>, which
is their term for a feature structure.  This is actually too weak a
statement.  Not just any feature structure is allowable here; it must be
a feature structure for agreement (which is defined in the complete
example at the end of the chapter to contain the features of person and
number).  The following feature declaration encodes this constraint on
the value range:

<eg>
<![ CDATA [
<fDecl name=AGR>
   <fDescr>agreement for person and number</fDescr>
   <vRange><fs type=Agreement></fs></vRange>
</fDecl>
]]>
</eg>

That is, the value must be a feature structure of type <code
type="value">Agreement</code>.  The complete example at the end of this
chapter includes the <tag>fsDecl type=Agreement</tag> which includes
<tag>fDecl name=PERS</tag> and <tag>fDecl name=NUM</tag>.</p>

<p>The PFORM feature indicates the surface form of the preposition used
in a construction.  Since PFORM is specified above as an open set,
<gi>str</gi> is used in the range specification below rather than
<gi>sym</gi>.

<eg>
<![ CDATA [
<fDecl name=PFORM>
   <fDescr>word form of a preposition</fDescr>
   <vRange><str rel=ne></str></vRange>
</fDecl>
]]>
</eg>

This example makes use of a negation.  <tag>str
rel=ne</tag><tag>/str</tag> subsumes any string that is not the empty
string.</p>

<p>The formal definition for feature declarations follows.  Note that
the class <ident type="class">featureVal</ident> includes all possible
single feature values, including a <gi>vAlt</gi>.

<eg id=dfdx>
<![ CDATA [
<!-- 26.3:  Feature definitions                               -->
<!ELEMENT fDecl         - -  (fDescr?, vRange, vDefault?)       >
<!ATTLIST fDecl              %a.global;
          name               NMTOKEN             #REQUIRED
          org                (unit | set | bag | list) 
                                                 unit           >
<!ELEMENT fDescr        - O  (%paraContent;)                    >
<!ATTLIST fDescr             %a.global;                         >
<!ELEMENT vRange        - O  (%m.featureVal)                    >
<!ATTLIST vRange             %a.global;                         >
<!ELEMENT vDefault      - -  ((%m.featureVal)+ | if+)           >
<!ATTLIST vDefault           %a.global;                         >
<!ELEMENT if            - -  ((fs | f | fAlt), then, 
                             (%m.featureVal) )                  >
<!ATTLIST if                 %a.global;                         >
<!ELEMENT then          - O  EMPTY                              >
<!ATTLIST then               %a.global;                         >
<!-- This fragment is used in sec. 26.1                       -->
]]>
</eg>
</p></div2>


<div2 id="FDfs"><head>Feature Structure Constraints</head>

<p>Ensuring the validity of feature structures may require much more
than simply specifying the range of allowed values for each feature.
There may be constraints on the co-occurrence of one feature value with
the value of another feature in the same feature structure or in an
embedded feature structure.</p>

<p>Such constraints on valid feature structures are expressed as a
series of conditional and biconditional tests in the
<gi>fsConstraints</gi> part of an <gi>fsDecl</gi>.  A particular feature
structure is valid only if it meets all the constraints.  The
<gi>cond</gi> element encodes the conventional if-then conditional of
boolean logic which succeeds when both the antecedent and consequent are
true, or whenever the antecedent is false.  The <gi>bicond</gi> element
encodes the biconditional (if and only if) operation of boolean logic.
It succeeds only when both antecedent and consequent are true, or both
are false.  In feature structure constraints the antecedent and
consequent are expressed as feature structures; they are considered true
if they <term rend="noindex">subsume</term>
<index level1="subsumption" level2="of feature structures">
(see section <ptr target="FDfd">) the target feature structure.  The
following elements make up the <gi>fsConstraints</gi> part of an FSD:

<list type=gloss>
<label><gi>fsConstraints</gi></label>
<item>specifies constraints on the content of well formed feature
structures.</item>
<label><gi>cond</gi></label>
<item>defines a conditional feature-structure constraint; the 
consequent
and the antecedent are specified as feature 
structures or
feature-structure groups; the constraint is 
satisfied if both the
antecedent and the consequent 
<term>subsume</term> a given feature
structure, or if the 
antecedent does not.</item>
<label><gi>bicond</gi></label>
<item>defines a biconditional feature-structure constraint; both

consequent and antecedent are specified as feature 
structures or groups
of feature structures; the constraint 
is satisfied if both
<term>subsume</term> a given feature 
structure, or if both do not.</item>
<label><gi>then</gi></label>
<item>separates the condition from the default in an <gi>if</gi>, 
or
the antecedent and the consequent in a <gi>cond</gi> 
element.</item>
<label><gi>iff</gi></label>
<item>separates the condition from the consequence in a 
<gi>bicond</gi>
element.</item>
</list>
</p>

<p>For an example of feature structure constraints, consider the
following <socalled>feature co-occurrence restrictions</socalled>
extracted from the feature system for English proposed by Gazdar, Klein,
Pullum, and Sag (1985:246-247):

<list type="simple">
<item>FCR 1:  [+INV] &rarr; [+AUX, FIN]</item>
<item>FCR 7:  [BAR 0] &equiv; [N] & [V] & [SUBCAT]</item>
<item>FCR 8:  [BAR 1] &rarr; ~[SUBCAT]</item>
</list></p>

<p>The first constraint says that if a construction is inverted, it must
also have an auxiliary and a finite verb form.  That is,

<eg>
<![ CDATA [
<cond><fs><f name=INV><plus></f></fs>
      <then>
      <fs>
         <f name=AUX><plus></f>
         <f name=VFORM><sym value=FIN></f>
      </fs>
</cond>
]]>
</eg></p>

<p>The second constraint says that if a construction has a BAR value of
zero (i.e., it is a sentence), then it must have a value for the
features N, V, and SUBCAT.  By the same token, because it is a
biconditional, if it has values for N, V, and SUBCAT, it must have
BAR=0.  That is,

<eg>
<![ CDATA [
<bicond>
   <fs><f name=BAR><sym value=0></f></fs>
   <iff>
   <fs>
      <f name=N><any></f>
      <f name=V><any></f>
      <f name=SUBCAT><any></f>
   </fs>
</bicond>
]]>
</eg></p>

<p>The final constraint says that if a construction has a BAR value of 1
(i.e., it is a phrase), then the SUBCAT feature is irrelevant (~).
This is not biconditional, since there are other instances under which
the SUBCAT feature is irrelevant.  That is,

<eg>
<![ CDATA [
<cond><fs><f name=BAR><sym value=1></f></fs>
      <then>
      <fs><f name=SUBCAT><none></f></fs>
</cond>
]]>
</eg></p>

<p>The DTD fragment for feature structure constraints is as follows.
Note that <gi>cond</gi> and <gi>bicond</gi> use the empty tags
<gi>then</gi> and <gi>iff</gi>, respectively, to separate the antecedent
and consequent.  These are primarily for the sake of enhancing human
readability.

<eg id=dfd2>
<![ CDATA [
<!-- 26.4:  Feature structure constraints                     -->
<!ELEMENT fsConstraints - -  (cond | bicond)*                   >
<!ATTLIST fsConstraints      %a.global;                         >
<!ELEMENT cond          - O  ((fs | f | fAlt), then, (fs | f | 
                             fAlt))                             >
<!ATTLIST cond               %a.global;                         >
<!ELEMENT bicond        - O  ((fs | f | fAlt), iff, (fs | f | 
                             fAlt))                             >
<!ATTLIST bicond             %a.global;                         >
<!ELEMENT iff           - O  EMPTY                              >
<!ATTLIST iff                %a.global;                         >
<!-- This fragment is used in sec. 26.1                       -->
]]>
</eg>
</p></div2>

<div2 id="FDeg"><head>A Complete Example</head>

<p>To summarize this chapter, the complete FSD for the example that has
run through the chapter is reproduced below:

<eg>
<![ CDATA [
<!DOCTYPE teiFsd2 SYSTEM "teifsd2.dtd">
<teiFsd2>
<teiHeader>
<fileDesc>
<titleStmt>
   <title>A sample FSD based on an extract from Gazdar
          et al.'s GPSG feature system for English</title>
   <resp>
      <role>encoded by</role>
      <name>Gary F. Simons</name>
   </resp>
</titleStmt>
<publicationStmt>
This sample was first encoded by Gary F. Simons (Summer
Institute of Linguistics, Dallas, TX) on January 28, 1991.
Revised April 8, 1993 to match the specification of FSDs
in version P2 of the TEI Guidelines.
</publicationStmt>
<sourceDesc><p>
This sample FSD does not describe a complete feature
system.  It is based on extracts from the feature system
for English presented in the appendix (pages 245-247) of
Generalized Phrase Structure Grammar, by Gazdar, Klein,
Pullum, and Sag (Harvard University Press, 1985).
</sourceDesc>
</fileDesc>
</teiHeader>
<!-- ************************************************** -->
<fsDecl type=GPSG>
   <fsDescr>Encodes a feature structure for the GPSG analysis
     of English (after Gazdar, Klein, Pullum, and Sag)</fsDescr>
   <fDecl name=INV>
      <fDescr>inverted sentence</fDescr>
      <vRange>
          <vAlt><plus><minus></vAlt></vRange>
      <vDefault>
          <minus></vDefault>
   </fDecl>
   <fDecl name=CONJ>
      <fDescr>surface form of the conjunction</fDescr>
      <vRange>
          <vAlt>
              <sym value=and><sym value=both>
              <sym value=but><sym value=either>
              <sym value=neither><sym value=nor>
              <sym value=or><sym value=NIL>
          </vAlt></vRange>
      <vDefault>
          <none></vDefault>
      </fDecl>
   <fDecl name=COMP>
      <fDescr>surface form of the complementizer</fDescr>
      <vRange>
          <vAlt>
              <sym value=for><sym value=that><sym value=whether>
              <sym value=if><sym value=NIL>
          </vAlt></vRange>
      <vDefault>
          <if><fs><f name=VFORM><sym value=INF></f>
                  <f name=SUBJ><plus></f></fs>
           <then><sym value=for></if>
          </vDefault>
      </fDecl>
   <fDecl name=AGR>
      <fDescr>agreement for person and number</fDescr>
      <vRange><fs type=Agreement></fs></vRange>
      </fDecl>
   <fDecl name=PFORM>
      <fDescr>word form of a preposition</fDescr>
      <vRange><str rel=ne></str></vRange>
      </fDecl>
   <!-- The complete analysis includes additional features -->
   <fsConstraints>
      <cond><fs><f name=INV><plus></f></fs>
         <then>
            <fs>
               <f name=AUX><plus></f>
               <f name=VFORM><sym value=FIN></f>
            </fs></cond>
      <bicond><fs><f name=BAR><sym value=0></f></fs>
         <iff>
            <fs>
               <f name=N><any></f>
               <f name=V><any></f>
               <f name=SUBCAT><any></f>
            </fs></bicond>
      <cond><fs><f name=BAR><sym value=1></f></fs>
         <then>
            <fs><f name=SUBCAT><none></f></fs>
            </cond>
   </fsConstraints>
</fsDecl>
<!-- ************************************************** -->
<fsDecl type=Agreement>
   <fsDescr>This type of feature structure encodes the features
      for subject-verb agreement in English</fsDescr>
   <fDecl name=PERS>
      <fDescr>person (first, second, or third)</fDescr>
      <vRange><vAlt><sym value=1><sym value=2><sym value=3>
         </vAlt></vRange>
   </fDecl>
   <fDecl name=NUM>
      <fDescr>number (singular or plural)</fDescr>
      <vRange><vAlt><sym value=sg><sym value=pl>
         </vAlt></vRange>
   </fDecl>
</fsDecl>
</teiFsd2>
]]>
</eg>
</p></div2></div1>
<!-- Keep this comment at the end of the file
Local variables:
mode: sgml
sgml-default-dtd-file:"~/lib/psgml/p2odd.ced"
sgml-parent-document:("/home/tei/P3/Master/Odds/p2.odd" "TEI.1" "TEXT" "BODY" "DIV1")
sgml-omittag:t
sgml-shorttag:t
End:
-->
             <!-- 26 Feature Struc. Decl. -->
