On Mon, 5 Feb 2001, Syd Bauman wrote:
|So, presuming PCDATA won't do, as more detailed encoding is needed,
|in order of preference I'd suggest
|1. Modify the DTD to allow a SECURITY element. (And send
| suggestion to TEI Editors so it might get added to future
| versions of TEI.)
|2. SEG with type= and perhaps subtype= for a controlled vocabulary
|3. RS with type=
|4. DATELINE with a sheepish explanation
No better than 3. I fear
|Remember, that with the advent of the pizza pages modifying the DTD
|is not particularly difficult. (Although this change is more than
|run-of-the mill: you'd have to both create your SECURITY element and
|add it to the content of OPENER and CLOSER by redefining those
|elements, too, as there is no content model class (i.e., easier to
|use parameter entity) for them.)
Not so: you could just add it to %m.divtop
|>Anyone know of a site that will validate remotely like the W3 HTML
|>markup checker http://validator.w3.org ?
|I'm embarrassed to admit I don't think so (embarrassed for myself that
|I don't know for sure, and embarrassed for the TEI Consortium that so
|obvious a service isn't available, or if it is available is so poorly
There used to be such a service on the OTA pages, and we could (I suppose) add one to the new TEi pages. But....
1. What dtd would you expect us to use to validate it?
2. SGML or XML?
3. What entities?
Is it really so hard for people to get hold of a quick fast validating
parser like rxp or sp ? Hey, I believe you can even get an xml parser
that works from Microslop these days...
| http://www.uic.edu/orgs/tei/sgml/pizza.html and
| http://www.hcu.ox.ac.uk/TEI/pizza.html; they are not the same,
| and each has advantages and disadvantages.
Please expound on what you consider these to be -- offlist if you like
-- since the former has no visible means of support, I'd like to be
sure we've snarfed all the advantages from it before it disappears!
| That is, your extension.ent file would need to have something
| <!ENTITY % opener "IGNORE">
| <!ENTITY % closer "IGNORE">
| and your extension.dtd file would need to have something like
| <!ELEMENT security - O EMPTY >
| <!ATTLIST security %a.global;
| level ( generalDistribution | internalOnly
| | strictlyPrivate | death2readers ) #REQUIRED >
| *** the following declarations are exactly like the TEI vanilla
| *** declarations found in teistr2.dtd, except that we've added
| *** SECURITY to the content model and required an end-tag
| <!ELEMENT %n.opener; - - (%n.signed; | %n.dateline; | security
| | %n.salute; | %phrase.seq;)* >
| <!ATTLIST %n.opener; %a.global;
| TEIform CDATA 'opener' >
| <!ELEMENT %n.closer; - - (%n.signed; | %n.dateline; | security
| | %n.salute; | %phrase.seq;)* >
| <!ATTLIST %n.closer; %a.global;
| TEIform CDATA 'closer' >
Or you could just put
<!ELEMENT security - - (#PCDATA) >
<!ATTLIST security (low|medium|high) "low">
in your TEI.extensions.dtd
<!ENTITY % x.divtop "security|" >
in your TEI.extensions.ent
And you're done. This would mean that <security> can only appear
outside <opener>, along with the other things at the top of a div, but
I dont see a problem with that. If youn really think it has to be
wrapped inside opener, then yes, the content model of opener needs
some careful revision.
| Note that the "- O", "- -" and " and required an end-tag" parts
| would be dropped if you're using XML instead of SGML.
Here's a gotcha. You MUST include these, whether or not you're
aiming for XML, if you plan to put this through the piuzzachef, since
the pizzachef only speaks SGML right now (even tho it outputs xml)
Also, I am
| not sure what, if anything, should be done with the TEIform attribute
| in a case like this.
If there were a pre-existing TEI element of which the <security>
element might reasonably be regarded as a specialization, then my vote
would be for you to specify its name here. The best candidate for that
is probably "seg", so you could specify that.
| Warning: I haven't tested these fragments.
But have you shored them against your ruine?
Lou Burnard http://users.ox.ac.uk/~lou