First of all, I've been holding off on responding to this thread because
I wanted to get a new version pushed out. I have now done so. The
new version contains a fair number of changes, including:
(1) Definition of a URN for our namespace and registration of said URN with
IANA.
(2) Allow material from other namespaces in Sieve XML.
(3) Specify the structured comment convention (this was implicit in the
stylesheet example but needed to become explicit).
(4) Addition of a compact Relax NG grammar.
(5) Made the handling of comments consistent.
(5) Cleaned up a number of bugs in the schema and stylesheet.
And now back to the discussion.
Let's try to keep this conversation on the path of concrete examples.
I agree and will try to do so.
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.
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 now valid according to both schema in the document.
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.
By some magic of XML specification buzzwords, I gather that the above
snippet can be declared valid or invalid by the schema definition.
Yes. As I explained previously, a schema gets to control whether or not
elements in other namespaces are allowed, and where. I have allowed them in
most of so-called "complex" elements, i.e., elements that in turn contain other
elements.
How are mixed-namespace documents like this handled by XML parsers /
editors / UIs / etc? Is it reasonable to disallow a mixed namespace like
this?
That reallly depends on the application. Keep in mind that this is a building
block, not a finished protocol or service. Even asssuming every application out
there ends up embedding elements from other namespaces, in a typical setup
you're going to use additional schemata to constrain those elements in various
ways. This is entirely reasonable - XML fully support the idea of having
multiple schemata in play for different namespaces.
Is there a reason not to allow such mixing?
IMO no.
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 is also fine, modulo a couple of details - you're missing the
necessary xmlns attributes to identify the namespaces and the <sieve:sieve>
wrapper around the entire script. Fixing these, you'd end up with:
<foomail:config xmlns:foomail="http://exammple.com/foomail";
xmlns:sieve="urn:ietf:params:xml:ns:sieve">
<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>
<sieve:sieve>
<sieve:control name="require">
<sieve:str>vacation</sieve:str>
</sieve:control>
<sieve:action name="vacation">
<sieve:str>I'm away on vacation.</sieve:str>
</sieve:action>
</sieve:sieve>
</foomail:sieve>
</foomail:sieves>
</foomail:user>
</foomail:config>
Of course this is just one possible variant out of many - you could use
different prefixes, or use no prefix for one of the two namespaces, you
could have an additional set of wrapper elemenets or even switch some
foomail elements to attributes and use fewer, etc. etc.
Ned