Ned Freed writes:
The other issue here is how to map this stuff to regular Sieve. The
stylesheet given in the appendix maps displaydata and displayblock
material into structured comments. This can easily be
extended/changed to cover the handling of material in other
namespaces. But do we want to formalize the structured comment
convention?
My desire for structured comments is vanishingly small. My two cents.
Finally, there's the issue of how to handle other comments, which
we've discussed in the past but may be worth revisiting now.
Currently regular Sieve comments are mapped to <comment></comment>
blocks rather than to proper XML comments. The reason for this is
that not all XML processors provide access to stuff inside of <!--
foo --> constructs, so comments may get lost when converting from
Sieve-in-XML back to regular Sieve. Do we want to continue to do
things this way?
It's a decent reason at least, but it doesn't make me very happy.
In any case, here's a concrete proposal for how to move forward:
(1) Add the necessary stuff to allow use of XML in other namespaces
whereever displaydata is currently allowed.
(2) Drop displaydata, making the use of namespaces required if you want
to embed other stuff inside of a Sieve-in-XML.
(3) Add a section defining the structured comment convention for
representing this other stuff in regular Sieve format.
(4) Change displayblock to just block, making it clear it can be used for
other sorts of groupings.
(5) Leave the current mapping of unstructured Sieve comments to
<comment></comment> blocks alone.
OK.
I wish I'd kept my mouth shut. So many of these things are just better
than some even worse alternative.
<comment> exists so that even bad XML processors must preserve comments
in a round-trip conversion, which seems weak justification. Not so weak
that I actively disagree, but weak enough to make me unhappy.
Arnt