... | ... | @@ -84,11 +84,11 @@ For example, a journal may have validation rules such as these: |
|
|
* There must be top-level sections entitled "Introduction", "Methods and Materials", "Conclusion[s]" and "Bibliography". ("Conclusion[s]" means the 's' is optional.)
|
|
|
* They must appear in that order.
|
|
|
* An "Acknowledgements" section may optionally appear after "Conclusion[s]" but before "Bibliography".
|
|
|
* No section name can be repeated at the top level. (It's okay for subsections.)
|
|
|
* Sections at lower levels may be named anything except the names given.
|
|
|
* No section name can be repeated at the top level. (It's okay to repeat subsection names as long as they avoid the top-level section names.)
|
|
|
|
|
|
The specific validation rules enforced by HTMLevator are tdb, based on requirements. We may also face a requirement to make these rules configurable.
|
|
|
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 internally to XSLT to enforce and perhaps express constraints, piping validation results directly into outputs and/or into a separate report (tdb).
|
|
|
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).
|
|
|
|
|
|
|