Nested sections not appearing correctly.

[krusynth]

For instance section 3 here http://marylandcode.org/g95-22F/

[krusynth]

34bacff gets these to show up at all, but there's definitely an issue with depth here.

[waldoj]

How does the originally imported XML represent this section? How about within text and text_sections—is everything stored properly there?

[krusynth]

The XML looks ok I think - I'm not sure exactly what's going on. Here's the file in question:

https://gist.github.com/krues8dr/6934934

and here's the current state of affairs:

http://dev.marylandcode.org/g95-22F/

between ii and iii it goes wonky.

[waldoj]

Yup, that XML is A-OK.

So the next thing to figure out is whether this is a problem at the time of import or at the time of display. That is, is there an incorrect depth and/or parent/child relationship as stored in the database, or as interpreted by the PHP after the data is pulled out of the database? I'd start by comparing the XML to the two MySQL tables for a(2)(iii). If that's OK, then we can dive into the rendering step.

[krusynth]

I'll look there (gotta jump on a call first) - at first glance, I'm wondering if resetting the depth to 1 in recurse() isn't to blame?

34bacff#diff-32b74f280059879320421db621c2fc65R384

[waldoj]

It's possible that should be $this->depth--. I remember spending several arduous days crafting that loop, trying a series of stupid ideas until I finally found an approach that worked. There was definitely nothing arbitrary about it. :) That said, I may not have tested it on a corpus of data that included adequately weird nestings.

[krusynth]

Hmm - something is definitely not right in there...

| id  | text_id | identifier | sequence | date_created        | date_modified       |
+-----+---------+------------+----------+---------------------+---------------------+
|   1 |       1 | a          |        1 | 2013-10-11 09:59:43 | 2013-10-11 09:59:43 |
|   2 |       2 | a          |        1 | 2013-10-11 09:59:43 | 2013-10-11 09:59:43 |
|   3 |       2 | 1          |        2 | 2013-10-11 09:59:43 | 2013-10-11 09:59:43 |
|   4 |       3 | a          |        1 | 2013-10-11 09:59:43 | 2013-10-11 09:59:43 |
|   5 |       3 | 2          |        2 | 2013-10-11 09:59:43 | 2013-10-11 09:59:43 |
|   6 |       4 | a          |        1 | 2013-10-11 09:59:43 | 2013-10-11 09:59:43 |
|   7 |       4 | 2          |        2 | 2013-10-11 09:59:43 | 2013-10-11 09:59:43 |
|   8 |       4 | i          |        3 | 2013-10-11 09:59:43 | 2013-10-11 09:59:43 |
|   9 |       5 | a          |        1 | 2013-10-11 09:59:43 | 2013-10-11 09:59:43 |
|  10 |       5 | 2          |        2 | 2013-10-11 09:59:43 | 2013-10-11 09:59:43 |
|  11 |       5 | ii         |        3 | 2013-10-11 09:59:43 | 2013-10-11 09:59:43 |
|  12 |       6 | a          |        1 | 2013-10-11 09:59:43 | 2013-10-11 09:59:43 |
|  13 |       6 | iii        |        2 | 2013-10-11 09:59:43 | 2013-10-11 09:59:43 |
|  14 |       7 | a          |        1 | 2013-10-11 09:59:43 | 2013-10-11 09:59:43 |
|  15 |       7 | iv         |        2 | 2013-10-11 09:59:43 | 2013-10-11 09:59:43 |

a2, a2i, a2ii, aiii, aiv. The "2" is being lost. Maybe I'm popping somewhere I shouldn't be...

[krusynth]

0129c66 seems to give the appropriate results. @waldoj is there another good data set for me to test against before pushing this upstream? Virginia maybe?

[waldoj]

Sure, Virginia's what I would have built this against in the first place, so if it works against Virginia, it at least works against the original test corpus.

(Sidenote: I really need to keep on hand a list of test sections—laws that are particularly nest-y, that have a mix of definitions scopes, that have a lot of citations in case law, etc.)

[krusynth]

@waldoj are you aware of any sections that have nesting that I can check? I think this still works...

[krusynth]

1-400 looks ok...

[waldoj]

Here's a decent one.

[krusynth]

Hmm, well that one is broken on the live site - should be B.1. not 1.1. I think? Also, B. should be a title above, and 1. should fall below with 2. and 3., etc. Mine shows the right lettering, but does the same running-together the live one has.

[waldoj]

Ah, yes—that's part of an existing issue that's related, explained most succinctly with this comment. It's actually a problem with Virginia's bulk data, although I have a theory of how to handle it.

Anyhow, if your code a) doesn't make things worse and b) actually makes things a little better, than that seems awfully good to me.