error of treatment of <app> within <app>

[arlogriffiths]

@michaelnmmeyer —

See screenshots.

The corresponding code is:

<p><app><lem type="omitted_elsewhere">ujar hala ulihniṅ <app><lem type="emn">paṅrəṅə̄</lem><rdg wit="#K">paṁṅr̥ṅa:</rdg></app> pūrvaka, inujarakən denikaṅ aṅrəṅə̄ sahakrodhānya ta ya, tuhu ta ya, ndan magavay alarāmbək riṅ len<supplied reason="implied">,</supplied> donya<surplus>,</surplus> inujarakən, ṅaraniṅ ujar maṅkana, vākpāruṣya ṅaranya<!-- #K inserts , --> liṅ saṅ paṇḍita.</lem><witDetail type="retained" wit="#K"/><note type="altLem">ujar hala ... liṅ saṅ paṇḍita</note><rdg wit="#L" cause="eye-skip"><gap reason="omitted"/></rdg></app></p>

The contents of App 1667 are also displayed in App 1666 where they do not belong.
Meanwhile, the information <rdg wit="#L" cause="eye-skip"><gap reason="omitted"/></rdg> and the fact that there is no #M reading here because the passage here falls inside a longer lacuna should be indicated in App 1666 but are not.

[michaelnmmeyer]

This type of stuff I will need time to fix. It's impossible to reason about correctness without a formal processing model.

[arlogriffiths]

I am willing and able to remain patient, though I am not sure what you mean with reasoning about correctness being impossible: the EGC discusses and illustrates the expected use and behavior of the relevant elements and the present display is clearly not correct.

Could you explain (in a different issue in project-documentation) what a formal processing mode, how it differs from the EGC- and EGD-based schemas (or anytthing else) that we have now, and what road map you propose for delivering what we need?

Work on the critical editions must move forward and checking the correctness of our displayed apparatus is best done immediately after the relevant part of the text has been encoded (because checking only at the end of the whole editing process will mean an enormous mass of apparatus entries need to be checked with greater risk of infelicities escaping attention). What about a temporary solution relying in the code that Axelle has put into place?

[michaelnmmeyer]

I was talking about a purely technical issue viz. how to convert our texts to HTML for display. This has no bearing on the encoding guidelines and even on display choices, it is merely about algorithmic choices. At this stage, I can reliably modify the validation code (we have a sound system in place), but modifying the HTML conversion code is a whole other matter.

The two issues you mentioned might seem innocuous, but they require a lot of work (and a lot of code) to be addressed properly. I can write something that sort of works (and I will do just that if required), but it would be very fragile and would cause other issues down the line. Right now I do not have a clear idea of how much time it will take, I need, say, a month to figure this out.

[arlogriffiths]

Thanks Michaël! Please do follow your own instincts as to what is a useful investment of your time at this stage. I mean that you could choose not to invest time in a fragile short-term solution if you are sure you can offer a robust solution in the longer term. Of course I can live with an imperfect apparatus in the Svayambhu edition as Tim Lubin and I are still quite a way from reaching the end of our edition. We shall keep this issue open as long as the problem remains unresolved.