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

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

2009-01-06 18:11:29

On Mon, Dec 29, 2008 at 8:26 AM, Alexey Melnikov
<alexey(_dot_)melnikov(_at_)isode(_dot_)com> wrote:
Ned Freed wrote:

But I'm sitll a little confused as to what you're asking for here. If
you're
asking for removal of the explicit inline XML syntax examples in favor
of a
more abstract approach, I'd be fine with that if there's a WG consensus
to make
such a change.


no - i'm very happy with the syntax examples
   i would like to see the approach used in RFC 5023 (and others)
adopted, adding a normative description of the XML and making the
schema only informative.


Personally, I find RFC 5023 approach, like the XOPEN object descriptions
it's
similar to, to be almost totally unreadable. Maybe it's the only
reasonable way
to do it when the element structure is quite complex, but that's not the
case
here.


Speaking as an individual: I tend to agree with Ned here. I prefer having
some formal syntax for defining XML + some examples demonstrating different
Sieve features.
I think adding a descriptive definition of XML is a fair bit of work for
little gain. However, I would not oppose to having some descriptive
definition (which I think should be informative), especially if somebody
suggests some text ;-).

(i'm unlikely to contribute to a flawed specification unless there is
some hope that it will be fixed)

using XML Schema as the formal definition means that decisions have to
be taken which are forced by the language which would not be required
by an alternative formal method.

1. a decision will be needed to either use the default namespace or
another namespace. this will mean either sacrificing user who are
still using parsers from the 1990s or sacrificing those who need
explicit namespacing.

2. a decision will also need to be taken about the mixture of domains.
mixing sieve with annotations about sieve means that the schema has to
be edited (to separate these concerns) before being used in modern
generators. unless this is supported at least implicitly by the
specification, it just means that an alternative specification will be
needed for these use cases.

ATM lack of namespace support and a failure to separate the concerns
in the design of schema means that the specification is useless to me
and many other developers using modern, namespace aware tools. by
applying methods used in other RFCs facing these issues, it should be
possible to create a specification suitable for both legacy and modern
tooling.

- robert

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