Ned Freed writes:
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.
I didn't reply... but at least I would have preferred such a meta thingy at 302 time. Now it may be too late.
I apologize for not being clearer here - I made this sound like it's a processor quality thing, which it isn't.
You were clear enough for me at least.
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.
Sure. The question is whether that's a problem.If you write a script in xmlsieve, convert it and then convert it back, then any comments you added may have been deleted. AFAICT this is not a problem.
If you write it in plain old sieve, convert it and then convert it back, then comments are preserved due to <comment>. AFAICT this is neat, but it's not clear to me that it's necessary. (Btw. Now that I think about it. Is whitespace preserved in arguments?)
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.
Yes. Arnt