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.
I don't think we have a choice. The problem is the XML representation is richer
and since it isn't intended as a storage format there has to be a way to map
the additional information to something in regular sieve. Unless we want to do
something along the lines of the meta extension Kjetil proposed - which I don't
think we want to do, pretty much the only place for it is in comments.
> 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.
I apologize for not being clearer here - I made this sound like it's
a processor quality thing, which it isn't.
The problem is more fundamental: In XML comments are not considered to be part
of the infoset. This means conforming XML processors are explicitly allowed to
drop them. Which in turn means you cannot count on them being available
for processing.
> 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.
This has been done in the new revision of the draft.
> (2) Drop displaydata, making the use of namespaces required if you want
> to embed other stuff inside of a Sieve-in-XML.
This has not. I don;t think we have consensus on this yet, and it is much
easier to remove something than to put it back in once it is gone.
> (3) Add a section defining the structured comment convention for
> representing this other stuff in regular Sieve format.
Done.
> (4) Change displayblock to just block, making it clear it can be used for
> other sorts of groupings.
Not done yet, as it kinda depends on the removal of displaydata to make
sense.
> (5) Leave the current mapping of unstructured Sieve comments to
> <comment></comment> blocks alone.
This was actually inconsistent in places and required some changes.
OK.
I wish I'd kept my mouth shut. So many of these things are just better
than some even worse alternative.
Yeah, that's the nature of the beast, I'm afraid.
<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.
Mostly agreed, except that such processors are in fact fully compliant and
therefore not considered "bad", at least in any sense that matters.
Ned