On Mon, Jan 12, 2009 at 11:25 AM, Arnt Gulbrandsen
<arnt(_at_)gulbrandsen(_dot_)priv(_dot_)no> wrote:
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.
modelling sieve comments as elements (as opposed to XML comments) is a
very natural and obvious way to map these domains and separates the
concerns of commenting on the XML serialization from comments in the
sieve script.
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.
XML comments tend to be difficult to preserve when transforming
documents and so on. XML binders are unlikely to support semantic
content in comments, so it's not just bad XML processors which are
going to have problems.
using an element to model the comment part of the grammar is very
natural and makes the relationship between the XML structure and the
sieve structure clear and obvious.
if a parser is generally expected to map the data block to sieve
comments, replacing both separate block structures with support for
structure comments would not only make this clear and obvious but
would mean that the XML structure would have a simple and obvious
isomorphism to the Sieve structure.
- robert