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

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

2009-01-12 09:03:27

On Mon, Jan 12, 2009 at 3:47 AM, Aaron Stone <aaron(_at_)serendipity(_dot_)cx> 
wrote:
On Sun, 2009-01-11 at 18:30 -0800, Ned Freed wrote:
so, just to ensure i understand this issue - you've decided to support
namespaces fully and drop support for namespace unaware parsers?

(FWIW this is fine by me)

Nope. I've decided not to specify any sort of "standard namespace prefix"
in the document. That's all.

I have no idea what you mean by "support namespaces fully". But given the 
tone
of your most recent responses I'm no longer willing to spend time in a
give-and-take trying to figure what you mean by this.

Let's try to keep this conversation on the path of concrete examples. I
had no idea what this entire thread was about until Robert gave a
specific XML snippet to illustrate what he wanted to do, and you gave a
different one in response to illustrate the document state.

this isn't what i wanted to do but it was intended to illustrate a
point. i will try to remember to include more examples in future,
though.

My current understanding from trying to follow this thread is that this
snippet (from Robert) is not valid according to the document:

    <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>

This is syntactically valid XML, but semantically the element from the
'mix' namespace isn't going to make sense to a naive Sieve-XML parser.

yes - i think this goes to the heart of the discussion

By some magic of XML specification buzzwords, I gather that the above
snippet can be declared valid or invalid by the schema definition.

How are mixed-namespace documents like this handled by XML parsers /
editors / UIs / etc?

it depends on the approach

generative approaches generally handle this poorly. hand crafted
approaches handle this fine. these days, using SAX directly is rare
and DOM is out of fashion (too slow) so generative approaches tend to
dominate (at least in the java and .NET).

generative editors struggle with semantically mixed domains: it needs
some clue about which are annotations and which are sieve. this can be
fixed by editing the schema to remove the annotations.

Is it reasonable to disallow a mixed namespace like
this? Is there a reason not to allow such mixing?

disallowing mixed means that the schema can be used directly to
generate a good domain model which maps easily to the nodes in a sieve
processor.

allowing mixing means that existing editors which use their own
annotations can be used reasonably directly. mixed content makes
binding more fiddly.

most likely, the XML binding would either need to be done by hand,
some kind of DOM used or a SAX filter with conventional XML binding
framework upstream. not a major issue when loading the XML directly
from a stream, quite possibly more difficult if you want to use a
framework of some kind (eg web services).

a secondary question is what library creators (as opposed to
application creators) should do when they encounter mixed markup. i
think it's reasonable just to ignore it and concentrate just on the
elements which have semantic meaning in sieve (but others may
disagree).

What if someone wants to use the Sieve-XML schema within a larger
document? For example:

   <foomail:config>
     <foomail:service service="smtp">
       <foomail:port>25</foomail:port>
       <foomail:listen>127.0.0.1</foomail:listen>
     </foomail:service>
     <foomail:user id="1">
       <foomail:name>Username</foomail:name>
       <foomail:sieves>
         <foomail:sieve>
           <foomail:name>On vacation</foomail:name>
           <foomail:script>
             <sieve:action name="vacation">
               <sieve:str>I'm away on vacation.</sieve:str>
             </sieve:action>
           </foomail:script>
         </foomail:sieve>
       </foomail:sieves>
     </foomail:user>
   </foomail:config>


this isn't usually such a problem since the foomail schema can either
specify any element, or just include sieve.

(this is very similar to SOAP so i'll include some general comments
about web services)

in practice, though, most generative approaches to web services don't
work that well with schema that include arbitrary elements. so, the
main issue would be whether the particular web service framework would
work without editing the schema.

- robert

<Prev in Thread] Current Thread [Next in Thread>