On 02/11/11 11:40, Dag Wieers wrote:
On Sun, 30 Oct 2011, Lex Trotman wrote:
On 30 October 2011 06:42, Dag Wieers <[email protected]> wrote:
On Sat, 29 Oct 2011, Lex Trotman wrote:
There is a very big problem with ODF where paragraphs inside paragraphs
are
not allowed. This means that we have to be very careful that this does
not
occur. Unfortunately, when doing odt.conf it is unclear how blocks are
nested, and how to prevent this from happening in the first place.
To me it's the biggest concern at the moment for ODF support :-/
Not wishing to put words in his mouth, but Stuart's answer in the past
has always been that asciidoc does not enforce backend restrictions,
see
http://www.methods.co.nz/asciidoc/faq.html#_asciidoc_sometimes_generates_invalid_output_markup_why
Hmm, that by itself makes (guaranteed) ODF support impossible.
Well no better or worse than any other backend, for docbook it is
possible to nest illegally in asciidoc too. (X)HTML nesting is so
liberal its rarely a problem.
Stuart,
I'd like to hear your opinion on this.
There are currently more than one occasion where nested paragraphs happen, and
either we need to track whether we are already inside a paragraph (so we can
adapt the output in such cases) or we need to rethink the whole thing.
But I don't think (silently) corrupting output as is now the case is an option.
I not only struggle with AsciiDoc's design, I also struggle with how output is
nested and how we can make this work with ODF :-/
Hi Dag,
Although AsciiDoc was designed to generate (but is not confined to) SGML type
markups it does not test or make any assumptions about what is or is not legal
in the the backend markup that it outputs (as per the FAQ).
This is a feature not a bug.
Consequentially the legality of AsciiDoc generated markup can only be tested by
a backend specific validator after asciidoc has been run (this is what a2x
does). This also leaves the user free to choose the validator and validation
options that best suits the flavor of markup they are targeting. The combination
of asciidoc plus external validator will always guarantee you never silently
generate invalid output (unless the validator is buggy, but that's not an
asciidoc problem).
Although the AsciiDoc syntax is configurable, AsciiDoc does impose a block
structure (and a default syntax) on the AsciiDoc source. AsciiDoc block elements
nest as follows:
1. Sections can contain sections.
2. Delimited blocks defined with the 'sectionbody' option can contain section
body elements (see
http://www.methods.co.nz/asciidoc/userguide.html#_delimited_blocks_2).
2. Lists can nest.
3. 'asciidoc' styled table cells can contain section body elements.
The semi-formal AsciiDoc block structure summary in the User Guide
(http://www.methods.co.nz/asciidoc/userguide.html#_block_elements) is an attempt
to spell this out, it glosses over the details but if you do err asciidoc should
emit a (hopefully helpful) error message.
Cheers, Stuart
I will make the odt backend run xmllint when Stuart approves or
provides an alternative to the a2x changes. (and when I get my machine
rebuilt from hard disk failure).
But xmllint does not consider this a problem, nor can it offer a remedy.
Well, if the ODF DTD allows nesting then Libreoffice is wrong if it
rejects it. If the DTD prevents it then xmllint should complain. If
the DTD is wrong then Oasis should fix it.
Whilst xmllint error messages are often cryptic, they do tell you what
you did wrong.
xmllint does not protest, however the ODF specification does not allow nested
<text:p>.
--
You received this message because you are subscribed to the Google Groups
"asciidoc" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/asciidoc?hl=en.
