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

[Aaron Stone <[e-mail]>]

On Sun, 2009-01-11 at 07:48 -0800, Ned Freed wrote:
> > no, not at all
> 
> > i'll explain at more length what i meant
> 
> > the draft does not allow xml from other namespaces within sieve
> > fragments. for example (assuming sieve is the default namespace and
> > mix is some other namespace), the following is excluded by the current
> > draft schema:
> 
> >      <control name="if">
> >        <mix:editor-specific foo='bar'></mix:editor-specific>
> >        <test name="header">
> >          <tag>is</tag>
> >          <str>Sender</str>
> >          <str>[e-mail]</str>
> >        </test>
> >        <action name="fileinto">
> >          <str>filter</str>
> >        </action> <comment>move to "filter" mailbox</comment>
> >      </control>
> 
> > does my comment make sense now?
> 
> Nope. First of all, it simply isn't true: The <displaydata> element is defined
> as an xsd:any without a namespace attribute (which defaults to ##any, meaning
> any namespace is allowed) and with a processContents attribute set to skip,
> meaning no schema is required for anything inside. So your example can be
> written:
> 
>       <control name="if">
>         <displaydata>
>           <mix:editor-specific foo='bar'></mix:editor-specific>
>         </displaydata>
>         <test name="header">
>           <tag>is</tag>
>           <str>Sender</str>
>           <str>[e-mail]</str>
>         </test>
>         <action name="fileinto">
>           <str>filter</str>
>         </action> <comment>move to "filter" mailbox</comment>
>       </control>
> 
> and be schema-valid. (Actually, I cheated a little here - the schema in the
> current draft has a bug where it is missing displaydata and displayblock in the
> first choice in the command type definition. This has to be fixed for the
> above to validate. But this has nothing to do with the use or non-use
> of other namespaces.)
> 
> Now, perhaps your objection is that you have to use displaydata containers in
> order to embed material from other namespaces and you don't want to have to do
> that. If so, that's easily remedied by adding some
> 
>           <xsd:any namespace="##other" processContents="lax"/>
> 
> directives. The equivalent in Relax is something like:
> 
>    any = element * { mixed { ( any | attribute * { text } )* } }
>    extelements = element * - ( local:* | sieve:* ) { any }*
>    extattributes = attribute * - ( local:* | sieve:* ) { text }*
>    extnodes = ( extattributes extelements)
> 
> 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.

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?

Aaron