If you have the TEI stylesheet library installed, there's a useful one
called oddbyexample.xsl (it's in the directory tools2) which will
generate a list of all the attribute values used in the directory of
texts you apply it to, in the form of an ODD file, from which you can in
turn generate HTML documentation and a schema, using Roma.
This is not dynamic, of course in the way that the other solutions
discussed here are, but it's still useful I'd suggest.
On 10/06/11 15:40, McAulay, Elizabeth wrote:
> Hi Ron,
> This probably won't work, but if you could build up a small batch and
> then generate the DTD from that, then that could be your baseline. New
> attribute values would have to
> be "approved" -- that is, sent in to you, and you can review and
> update the DTD. I guess this seems awkward for any kind of sizeable
> project, especially if the attribute values are for personal names or
> something like that. For projects I've worked on that have an ever-
> growing list of values, we have used a database or google spreadsheets
> as a source list that we can consult and add to. That's very manual,
> but it works.
> On Jun 10, 2011, at 7:24 AM, "Ron Van den Branden"<[log in to unmask]
> > wrote:
>> Hi Torsten,
>> Thanks for your suggestion.
>> On 10/06/2011 14:40, Torsten Schassan wrote:
>>> Now that you want to program anyway (either to use a DTD or schema,
>>> would be all the same), wouldn't it be an idea/alternative to run
>>> through your documents in advance and generate the DTD from what you
>>> find there and have an always "up-to-date" value list? If you now
>>> to enter another value, Oxygen will remind you that the value has not
>>> been used before but then you just would save your "invalid"
>>> re-run the DTD-generating script and after that your document is
>>> valid. Additionally, saved away in the DTD, you can share the lists
>>> with others who might be interested?
>>> Accessing your documents with Java in run time might be time costly
>>> anyway so it might be faster to have such a stand-alone program/
>>> and run it as described?
>> I've thought about this option as well, but this would require careful
>> instruction and assessment of computing skills since the encoders are
>> located elsewhere and not familiar with XML (hence the Author
>> environment). OTOH, if it could be done with a simple batch script
>> invoking an XQuery script (that doens't mess up the DTD), it could be
>> worth a try. Hmm, maybe there's a possibility of doing the work
>> inside eXist and using triggers to update the DTD (and backup the db)
>> when a document is updated. But I'd like to keep it as simple as
>> possible for the encoders.
>>> Anyway, if you progress with the programming in the Oxygen
>>> environment, I would be highly interested to learn about it.
>> Me too ;-).