On Wed, Jan 7, 2009 at 7:38 PM, Ned Freed
<ned(_dot_)freed(_at_)mrochek(_dot_)com> wrote:
Alexey Melnikov writes:
If we want to allow for magic comments, it make sense for them to be
in a separate namespace. But then magic comments are typically
implementation specific. So I unless we want to startadize them, I
don't think the document needs another namespace.
Each generator may want to use a namespace of its own for its particular
foo. I am not an expert in this. If that's considered good XML taste,
then that should be illustrated in an example or two.
I certainly want to allow that - indeed, I don't know of a way to disallow
it.
But I don't want to require this approach.
AFACT the current draft does not allow mixing of namespaces
Say what? All the current draft does is define a way to represent Sieve scripts
in XML. Nowhere does it specify how the resulting representation is to be used.
It could be used as a standalone thing where a given XML object only contains
Sieve content and nothing else. Or it could be used to embed Sieve material
inside of some more general sort of XML content (of course using namespaces to
keep things clear) - which in fact is exactly one of the ways we're using it.
You appear to be confusing this specification with others the IETF has done
that use XML as part of defining a protocol, e.g., XMPP. In such cases where
the goal is specifically for clients and servers written by different people to
be able to interoperate and that means there have to be tight constraints on
what can appear on the wire.
Sieve-in-XML is not a protocol or service. It is at most a tool someone can use
in building a protocol or service that needs to operate on Sieve content.
Exactly how it would be used to, say, have a Javascript-based Sieve editor
fetch and return Sieve content from a central server would require considerable
elaboration beyond what's already there. (This would be true even if XML were
not involved - I would expect in many cases for applications to require certain
Sieve extensions be supported and possibly be unable to deal with some others.)
Here's a concrete example of how this might play out. Suppose we decide to
define an extension to the managesieve protocol to allow clients to fetch and
store sieves using the XML representaation. In addition to the usual rigamarole
of having to specify the extension name, new commands or arguments, and so on,
such an extension would have to specify exactly what sort of XML would be used.
Are namespaces allowed? Required? Can other content be included in the XML or
is it forbidden?
I actually toyed with the idea of including a managesieve extension in this
specification for fetching and returning XML. I eventually decided against it
because I was concerned that we might run into the problems that have plagued
similar specifications in the past, most notably the abortive attempt to define
XCal, an XML representation of iCal. To the extent such specificastions look
like they are attempting to replace an original format with an XML-based one,
there has been opposition from people who are not, shall we say, believers in
the XML religion. This is also the reason I avoided coining any sort of cute
name for this like XSieve.
Ned