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.
If it was in the base specificaiton, maybe. But having to support a brand new
Sieve extension in order to handle preservation of XML content while round
tripping scripts sounds like a bad idea to me.
> 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.
Well, I don't know about you, but if I have a complex script that I have
carefully commented, and when I use a new GUI editor on it that transforms it
to XML and back again and loses the comments in the process, I'm not going to
be a happy camper.
Sure, there are lots of cases where it doesn't matter and comments can be
dropped, assuming there are any there in the first place. But there are
going to be cases where comments need to be preserved and any mapping
needs to support that.
Really, I think this is just lack of familiarity with how things play out in
the XML world more than anything. Everywhere you look in XML-based
languages you'll find <comment>, <annotation>, and similar constructs.
For better or worse, XML just doesn't worry too much about this stuff.
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?)
Whitespace in string constants darned well better be preserved. (And come to
think of it, I need to put in something about how to map text: constructs.)
Whitespace in comments can also be preserved for the most part - there may be
some edges where it's a bit difficult. But whitespace between lexical tokens in
either representation isn't going to be preserved. The solution I adopted in
the sample stylesheet was to output stuff using a simple indentation scheme.
Ned