> ... richer encoding of the different pieces of information
> in the OPENER, ...
> ... things like "Strictly Private" when they appear with
> the more usual DATELINE/SALUTE suspects. It would certainly
> be of interest to be able to pull up all the restricted
> documents. Nothing in OPENER seems appropriate, but OPENER
> seems to be the obvious location for
> this information.
Some quick thoughts.
* You can have have PCDATA directly inside OPENER. May not
be very helpful, but it least it's possible.
* SEG is a general-purpose phrase-level element that could
certainly be drafted into use:
<date value="2001-02-02">Fri, GH day</date>
<seg type="security" subtype="PVT">Strictly Private</seg>
* If you don't mind tag abuse, DATELINE could be forced
into this role, I suppose. (I don't like this, though.)
* It is quite reasonable to hold that the elements specific to
OPENER and CLOSER are inadaquate to your purpose and to expand
their scope or to add a new one altogether. We have done just
this at the WWP, where we have re-named BYLINE to RESPLINE and
expanded its semantics to include attributions of contribution
other than primary authorship, e.g., "Translated by Ms. Babe L.
Fish" would be a RESPLINE. In your case, it might make the most
sense to add a new element SECURITY which would have a type=
attribute with a controlled vocabulary, e.g. "public",
"internal", "confidential". Ask here (TEI-L) if you don't know
how to go about making such changes to the DTD.
There's probably more to it than this, but this is a start.
 I.e., SIGNED, DATELINE, & SALUTE; note that BYLINE is not in this
group, although it probably should be. This was reported to the
editors as an error on 2000-06-08:
The text of P3 says about OPENER and CLOSER:
groups together dateline, byline, salutation, and
similar phrases appearing as a ...
This text is copied directly from p3.p3x, where it appears
<xptr doc="p3.p3x" from="id(DSdtb)child(2 p)(1 list)(4 item)">
<xptr doc="p3.p3x" from="id(DSdtb)child(3 p)(1 list)(2 item)">
<xptr doc="p3.p3x" from="id(DSoc) child(3 p)(1 list)(1 item)"
to="ditto next(1 item)">
The content models for OPENER and CLOSER, however, do not
permit BYLINE. If the [source] text said "<gi>byline</gi>",
I would say the DTD is in error, pay up guys. But in fact
it has "byline", so I'm not really sure whether the DTD
is in error or the text is. (I suspect the DTD.)
For those who have the green books rather than the p3x source
file open, those XPTRs point to
section 7.2, bottom of page 225,
section 7.2, top of page 226, and
section 7.2.2, middle of page 228
Note that the list of parent elements of BYLINE on page 881 does
not list OPENER and CLOSER -- these lists were generated directly
from the DTD, I believe.