[tei-council] TD exemplifications

Syd Bauman s.bauman at neu.edu
Tue Jan 7 15:53:12 EST 2014


Martins replied on 2014-01-04T08:34:08-0800 --

MH> I would go for b) here. Simpler by far than anything else, and this is 
MH> surely a very isolated issue of meta-meta-documentation.

SR> if you can find a way to make egXML work inside egXML, I am
SR> interested.

SR> I=92d start by seeing if it actually works with the current
SR> processing chain first, then worry about validity. One or
SR> other of the two may be easy to fix.

Fixing the validity ought to be pretty easy, no? Just change the 2nd
line of
| macro.anyXML =
|   element * - (ns2:* | egXML) {
|     attribute * { text }*,
|     (text | macro.anyXML)*
|   }
to read
|   element * - ns2:* {

But fixing the processing chain is something I know nothing about.
What is the problem in processing, Sebastian? I.e., what makes it
hard to handle <egXML> inside <teix:egXML>?

If it turns out fixing the processing is as hard as Sebastian
implies, I think my order of preference is (d), (b), (c), (a).

> Indeed, that is an interesting problem and recurring problem. I think
> the only solutions are to either
> 
> a) remove the restriction on <egXML> nesting (I can't quite remember
>    why we have it, at the moment)
> 
> b) leave it as it is -- it doesn't get validated, such is life
> 
> c) change it to an <eg> -- it doesn't get validated, such is life
> 
> d) change the namespace of the internal <egXML> element to something
>    else, e.g., "http://www.tei-c.org/USE-PROPER-NAMESPACE-HERE", with
>    an explanatory sentence in the prose.


More information about the tei-council mailing list