Print

Print


I didn't see your earlier posting of this query. But here's an answer as
quick as I can make it!
 
L
 
>1. Is it possible to add an attribute for an element via a %x....
> construction or similar, or does one have to perform surgery on the
>   main DTD files? We need TYPE on several elements which don't have it.
 
You can redefine attribute classes, by redefining the associated
entities. So, for example, if you wanted to add an attribute INTERESTING
to all members of the DIVN class, you could do so simply by redefining
the %a.divn parameter entity in your dtd subset. If the elements for
which you want to add a new attribute are not all members of some class,
you might want to define such a class to simplify the business of adding
this attribute to all of them (and to ensure you do it consistently).
You would then have to undefine each element and redefine it including
the parameter entity reference %a.mynewclass in  their definition.
 
Entity definitions go in tei.extensions.ent, attribute and element
declarations in tei.extensions.dtd
 
All this should only be done with GREAT CARE and a proper understanding
of how the class mechanism (described in chapter ST of P3, and indeed in
my rather fine little paper at http://info.ox.ac.uk/~archive/teij31/)
works.
 
>2. I've been developing an OmniMark TEI-->HTML...despite sentiments
>   expressed here, it is pretty good, and _very_ fast. However, its
>   parser is gagging where others don't, and I don't understand why.
>
>   Currently we say:
>
><!DOCTYPE TEI.2 SYSTEM "tei2.dtd" [
><!ENTITY % TEI.corpus.dtd    'INCLUDE'>
><!ENTITY % TEI.prose         'INCLUDE'>
><!ENTITY % TEI.verse         'INCLUDE' -- can we do this as well as prose? -->
 
No you can't! That's what the various parsers are complaining about! You
can only select one (1) base tag set, unless you are using either
TEI.mixed or TEI.general. See  p.43 "If the documents requires tags
which are defined in different base tag sets, then one of the mixed-type
bases must be used" ; section 3.4 starting on the same page elucidates
this point further.
 
><!-- Modification to get round omission in TEI DTD, courtesy of LB -->
><!ENTITY % x.data '%n.persName | %n.placeName | %n.orgName |'>
 
This should no longer be necessary if you have the most recent TEI
tagsets, by the way.
 
>Emacs psgml-mode likes all this and we edit away happily. RulesBuilder
>likes it, and so A/E is also in use. But sgmls gripes when we parse a
>file, but still goes ahead and parses to the end of the instance OK:
>
>sgmls: SGML error at teihdr2.dtd, line 54 in declaration parameter 4:
>       Content model is ambiguous
 
sgmls is quite correct to complain. If you don't have a mixed or general base,
your definition for compo.seq will be ambiguous. This is not to be lightly
ignored!
 
>But OmniMark gives the same `ambiguous' message and comes to a grinding
>halt. I was under the impression that this message was to be expected
>with the TEI, because of the nested complexities, and was in the nature
>of a warning, not a fatal error.
 
No.It isn't a warning, it's WRONG WRONG WRONG.
 
>I'm asking here first, but CCing this to Exoterica, as I don't know at
>this stage if it's a TEI or OmniMark matter, and I hope to avoid any of
>those "it's their code"/"it's their DTD" differences of opinion :-)
 
No differences of opinion are likely on this one. I'm sure Omnimark will
agree that ambiguous content models are WRONG. The only reason psgml or
RB don't report them is (maybe) that their parser technology is not as
good as Exoterica's or James Clark's!
 
Lou