... | ... | @@ -16,6 +16,8 @@ XSweet can convert paragraphs `p` elements in HTML into `h1-h6` elements. It use |
|
|
|
|
|
## Structural induction
|
|
|
|
|
|
(What follows remains from original notes as to requirements: see the repository readme for up to date description of the implementation.)
|
|
|
|
|
|
Any sequence of HTML elements leading with a header (h1-h6) is wrapped as a section. Within each section, the header plus its (block level) elements are followed by sections for contiguous (subsequent) lower level sections.
|
|
|
|
|
|
I.e. h1 h2 h2 h3 h1 h2 h3 becomes section (h1 section (h2) section (h2 section (h3) ) ) section (h1 section (h2 (section h3) ) ).
|
... | ... | @@ -74,14 +76,14 @@ skipping levels at the front; |
|
|
skipping levels inside)
|
|
|
|
|
|
|
|
|
## *section type inferencing*
|
|
|
## section type inferencing
|
|
|
|
|
|
(At time of writing, these requirements are not addressed by HTMLevator.)
|
|
|
|
|
|
Means recognizing, for example, a **Conclusions** section (by means of its title and/or other properties) and submitting it to appropriate handling -- including validation, to detect whether and where such a section is required, expected or permitted. HTMLevator currently does not provide for section type inferencing, except to note that it is a natural requirement and one that can be readily accomplished in this architecture.
|
|
|
|
|
|
On HTML files whose section levels are *regularly* and *systematically* indicated by a "regular order" of headers, the XSLT provided here will reliably create a nested section structure.
|
|
|
|
|
|
More details:
|
|
|
|
|
|
## For future development - validation of structures/content types
|
|
|
|
|
|
Once structures have been induced (inferred or projected over the element sequence), they need to be validated against rule sets appropriate to their workflows.
|
... | ... | @@ -97,5 +99,3 @@ For example, a journal may have validation rules such as these: |
|
|
The specific validation rules enforced by HTMLevator are tdb, based on requirements. We also expect to face a requirement to make these rules configurable. This may be done via a "driver" config file or a meta-stylesheet (a la Schematron).
|
|
|
|
|
|
For now, we presume we will use XPath within XSLT to test against constraints, piping validation results directly into outputs and/or into a separate report (tdb). |
|
|
|
|
|
|