reverse_adoc: List item depth is dependent on context

[ronaldtse]

I used this command to test the document:

bundle exec reverse_adoc -rcoradoc/reverse_adoc/plugins/plateau --split-sections 2 --external-images -o plateau/index.adoc index.html 

File:
plateau/sections/section-09/section-02.adoc:

[[toc9_02_01]]
==== 　拡張規則

標準製品仕様に定義されていない地物や地物属性・地物関連役割を用いたい場合は、以下に示す規則に従う。

　

[none]
** 規則1：標準製品仕様に定義されておらず、i-URに定義されている地物又は地物属性・地物関連を使用したい場合は、i-URから必要な要素を抽出し、i-URの定義と矛盾なく使用する。

** 規則2：標準製品仕様に定義されておらず、CityGMLに定義されている地物又は地物属性・地物関連を使用したい場合は、CityGMLから必要な要素を抽出し、CityGMLの定義と矛盾なく使用する。

** 規則3：標準製品仕様に定義されておらず、i-UR及びCityGMLのいずれにも定義されていない地物を使用したい場合には、CityGMLに定義されたgen:GenericCityObjectを使用して、地物を追加する。
[none]
*** 注記：i-UR又はCityGMLに該当する地物が存在する場合には、gen:GenericCityObjectを使用してはならない。

** 規則4：標準製品仕様、i-UR、又はCityGMLのいずれにも定義されていない地物属性を使用したい場合には、CityGMLに定義されたgen:_genericAttributeの下位型を使用して、これを該当する地物に追加する。
[none]
*** 注記1：標準製品仕様、i-UR又はCityGMLに該当する属性が存在する場合には、gen:_genericAttributeを使用してはならない。

*** 注記2：「建築物」にコード型の地物属性を追加したい場合には、「建築物」に定義された「拡張属性」の仕組みを利用し、コード型の地物属性を追加する。

** 規則5：規則1、2又は規則4に従い、地物属性を追加する場合において、コード型の属性を定義する場合には、必ず、参照すべきコードリストを作成しなければならない。
[none]
*** 注記：コードリストの形式は、GML 3.1.1 simple dictionary profile (1.0.0)に従う。

** 規則6：規則1から規則5までに示す拡張規則に従い、標準製品仕様を拡張する場合には、拡張の内容を示す製品仕様を作成しなければならない。
[none]
*** 注記：製品仕様の作成においては、地理空間データ製品仕様書作成マニュアル[4]に従うこと。

In AsciiDoc, lists always start at the first level:

* level 1
** level 2
*** level 3

So this produced text is technically invalid AsciiDoc.

It should be:

[none]
* 規則1：標準製品仕様に定義されておらず、i-URに定義されている地物又は地物属性・地物関連を使用したい場合は、i-URから必要な要素を抽出し、i-URの定義と矛盾なく使用する。

* 規則2：標準製品仕様に定義されておらず、CityGMLに定義されている地物又は地物属性・地物関連を使用したい場合は、CityGMLから必要な要素を抽出し、CityGMLの定義と矛盾なく使用する。

* 規則3：標準製品仕様に定義されておらず、i-UR及びCityGMLのいずれにも定義されていない地物を使用したい場合には、CityGMLに定義されたgen:GenericCityObjectを使用して、地物を追加する。

[none]
** 注記：i-UR又はCityGMLに該当する地物が存在する場合には、gen:GenericCityObjectを使用してはならない。

[hmdne]

This issue turns to be much harder to do, due to Coradoc structure being a single linked tree, but not only that. The incoming document is not semantic HTML - each list item is <ul><li>list item</li></ul> only having indentation level specified via CSS. So do the non-list paragraphs - the CSS property sometimes does mean just indentation, sometimes it means a paragraph to supplant a list item. Despite sounding like a simple issue, it is far lot more complicated, while the logic we have currently is already complicated enough.

I have spent numerous hours pondering about the best solution for that and I suppose the best way to handle this issue will be in the linter, with linter having to reparse the document. If we go with that solution, we will have to have a complete parser that will be able to parse the entire incoming document.

[opoudjis]

+1 on making this a preprocessing task of some kind: your software cannot be made to deal with all the inanity that people will come up with in their HTML, nor assume that the HTML you will see will be clean and well-structured.

[ronaldtse]

I don't have the exact HTML on hand to discuss.

However, let's use the following sample HTML to demonstrate what I mean:

<ul>
  <ul><li>list item 1</li></ul>
  <ul><li>list item 2</li></ul>
  <ul>
    <ul><li>list item 3</li></ul>
  </ul>
</ul>

I am purposefully ignoring CSS here.

If you naively consider <ul> as 1 level, you will see

The corresponding AsciiDoc representation is:

* // blank
** list item 1
* // blank
** list item 2
* // blank
** // blank
*** list item 3

1. If we allow empty list items, then the above transformation is correct.
2. If we don't allow empty list items, then the "normalized" form is:

* list item 1
* list item 2
* list item 3

In any case, it never becomes this (which is current behavior):

** list item 1
** list item 2
*** list item 3

[hmdne]

Then we have two different issues.

The issue described in first post is specifically only for PLATEAU documents and this code is not generated from <ul><li> but from their CSS classes. And this code is not generated by reverse_adoc proper, but by PLATEAU plugin.