[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