Re: draft-freed-sieve-in-xml status?

[Ned Freed <[e-mail]>]

> > So I guess the question for the group here is what extensibility model do we
> > really want here? Do we want to require enclosure of material from other XML
> > sources in displaydata blocks, or do we want to allow other stuff to appear
> > without such blocks as long as it's in another namespace?

> I plead ignorance to the finer details of the XML Schema stuff described
> above, but off the cuff, not requiring displaydata seems cleaner to me.

Unfortunately, it's not quite that simple. The question is whether or not to
require the use of namespaces in order to embed stuff inside of a Sieve script
expressed in XML.

Both XML Schema and Relax let you say "allow any additional elements you want
here as long as it's in a different namespace". Alternately, you can say "allow
absolutely anything here", but if you do that you have to put  it inside of a
container element of some sort, which is exactly what
<displaydata> is.

What you cannot do is simply allow arbitrary content in the same namespace at
the same level as other elements that are schema validated. (Actually, you can
specify something like this in Relax, but the result is that you're validating
almost nothing.)

> Is the reason for the displaydata tag to tell an otherwise ignorant
> Sieve-XML-only program that the contents of the displaydata should be
> handled as verbatim data?

Yes, more or less. There has to be some indication that this content lies
outside the Sieve schema. That can done either with a namespace label or
with a container element.

So if we want to rely on namespaces, which IMO is a fine thing to do, we can
simply loosen the schema to allow material from other namespaces in and drop
displaydata entirely. (Displayblock, OTOH, still serves a useful purpose - you
need something like it to provide a higher level grouping construct.)

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?

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?

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.

Comments?

				Ned