ietf-mta-filters
[Top] [All Lists]

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

2009-01-11 14:12:59

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>owner-ietf-mta-filters(_at_)imc(_dot_)org</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>owner-ietf-mta-filters(_at_)imc(_dot_)org</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