`<egXML>` should be able to nest

[martindholmes]

We nest <egXML> in the Guidelines, for the perfectly straightforward reason that we need to give examples of how to use <egXML>. But this is currently invalid. @sydb and @martindholmes believe it should be valid.

[joeytakeda]

I filed a similar issue a while back, here: #1798.

[peterstadler]

Hah, this made my day: https://github.com/TEIC/TEI/issues/1798#issuecomment-409087128 Sorry @martindholmes , I couldn't resist :-)

[martindholmes]

@peterstadler I could say "A foolish consistency is the hobgoblin of little minds," but I'd be lying. :-) But when I made that comment I thought @joeytakeda was writing code to process his own nested <egXML>s, which is something I would do my best to avoid doing. We already have it in the Guidelines, though, so we ought to make it valid and workable.

[peterstadler]

Indeed, all references at https://en.wikiquote.org/wiki/Consistency show that consistency is nothing to pursue!

[martinascholger]

Related issue #1857

[peterstadler]

Related issue #1857

This is #1857 ?!?

[martindholmes]

@peterstadler I wonder if @martinascholger meant #1798?

[martinascholger]

Ups. Yes, I meant #1798 and wanted to have this specific icon referencing the related issue.

[jamescummings]

Where do we nest egXML in the guidelines except in providing examples of egXML? I don't think this is something we should encourage, except in documenting the way a project provides examples in its encoding guidelines. I'm not sure that level of meta-ness is really required since it isn't about explaining document instances.

[sydb]

Council F2F thinks that since the stuff in the examples namespace is not TEI, and (we think) can be validated with either NVDL or RELAX NG w/o DTD compatability mode, we should be able to tuck <egXML> inside <egXML>. The only loss will be that the resulting document would kick off a dreaded ID/IDREF error if a user tried to validate it with RELAX NG w/ DTD compatability mode (which is the default in oXygen). We can add a para warning about this in the prose of P5, and not do it in our own build process.

[martindholmes]

@sydb I don't think idref checking has anything to do with whether this is valid or not. the egXML spec file is invalid against tei_all both with it turned on and with it turned off, giving the error "egXML not allowed here" (i.e. inside egXML). I think it's only possible to validate it using NVDL.

[ebeshero]

Council notes that <egXML> should contain anything, so why wouldn't this be allowed? We have green-lighted this so to repair. Checking it with TEI-all yields an RNG error, but P5 ODDs is okay with it. @sydb notes that there may be a Stylesheets processing issue to investigate.

[hcayless]

Here's the problem:

  <define name="anyElement-egXML">
      <element>
         <anyName>
            <except>
               <nsName ns="http://www.tei-c.org/ns/1.0"/>
               <name ns="http://www.tei-c.org/ns/Examples">egXML</name>
            </except>
         </anyName>
         <zeroOrMore>
            <attribute>
               <anyName/>
            </attribute>
         </zeroOrMore>
         <zeroOrMore>
            <choice>
               <text/>
               <ref name="anyElement-egXML"/>
            </choice>
         </zeroOrMore>
      </element>
   </define>

[sydb]

So it turns out this does need discussion because the problem is in the Stylesheets magic that generates patterns to avoid the dreaded conflicting ID/IDREF problem. That said, it is such an edge case that it is quite low priority.