Yes, I did start on the task last night but got swamped by other things
today. The great merit of using an ODD to represent your proposal (aside
from saving the editors work!) is that it does actually force you to
think about how your new components interact with the rest of what's
It's also a lot easier, in my view. For example: you want <appInfo> to
appear inside <encodingDesc>. If you check the content of <encodingDesc>
as defined in P5, you will see that is defined by reference to the class
model.encodingPart. Ergo, to get your new element in there all you need
do is specify that it is a member of that class. Inside
elementSpec/classes you provide a <memberOf key="model.encodingPart"/>
and that's it.
Looking more closely at the proposal last night I was also struck by the
fact that the proposed application seemed rather narrow in scope --
basically for an annotation tool to record in the header which bits of
the document it had processed when. Seems to me it might be more
TEI-like to generalise this: I had envisaged a general purpose element
which could be used by any application program to record whatever data
it wants, provided it can be constrained usefully as name-value pairs (a
bit like it's done in java, I understand)
I'm also less and less convinced about the need for a global tools
attribute. If you just want to indicate within the document which parts
have been processed, I think that could be done by pointing from the
<appParam name="lastRun"><date value="2006-10-01"/></appParam>
<appParam name="sectionsTouched"><ptr target="#sec1"/>
<appParam name="resultStatus">dismal failure</appParam>
Alternatively, since this really is a processing matter of limited or no
interest in interchange, why not use a processing instruction?
<?myWizBang wuz-ere 2006-10-01?>
On Thu, 2006-06-08 at 05:07 -0700, Martin Holmes wrote:
> Thanks Christian. If Lou hasn't already done it, I can create an ODD
> file in the next couple of days. I was a bit confused by the fact that I
> couldn't actually find a single ODD file that represented the gaiji
> module; it looks as though individual elements go into their own ODD
> files, but I guess a change can be presented in the form of a single ODD
> file with multiple elementSpecs in it.
> I hadn't realized what Ch. 27 was about. I'd assumed it related to
> elements used for the documentation of a particular markup project.
> Christian Wittern wrote:
> > Martin Holmes <[log in to unmask]> writes:
> >> Would I be right in thinking that the appropriate way to propose an
> >> addition to P5 would be in the form of an RNG file like the one above?
> >> Or should I be creating a series of files containing elementSpec tags?
> > The latter. They go in something called an ODD file, described in
> > Chapter 27, "Documentation Elements". BTW, the "gaiji" module is
> > defined and described in Chapter 25, "Representation of non-standard
> > characters and glyphs".
> > Christian