On Wed, Jan 7, 2009 at 12:07 AM, Ned Freed
<ned(_dot_)freed(_at_)mrochek(_dot_)com> wrote:
(i'm unlikely to contribute to a flawed specification unless there is
some hope that it will be fixed)
First of all, there is no such thing as a perfect specification; they are all
flawed to some extent. It's the nature of the beast.
Second, and perhaps more to the point, we demand rough consensus on
specifications, nothing more. I could probably list a couple of things I'm
unhappy about or don't agree with in any specification I've participated in
developing, and for the major ones I can easily list a dozen issues or more.
Once more this is the nature of the beast. But the fact that I didn't agree
with the consensus on some points - and in some cases on many points - didn't
prevent me from contributing to those efforts.
thanks for the explaination
we're currently adding xml serialisation for jsieve over at apache.
there are number of concrete use cases that this serialisation needs
to satisfy. the current draft is currently unsatisfactory so we'll
probably just need to go ahead and create a competing standard. i
think this would be a shame.
my experience on this group hasn't exactly been pleasent for me
(thankfully most of the name calling has been in private). there don't
seem to be very many other implementators on this list with my
background so i'm consistently in a monority of one here. i'm unlikely
to waste energy contributing to a competing standard.
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.
Which is now irrelevant since we're not using XML Schema any more.
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.
Perhaps I don't understand what you're after here, but since the specification
now defines a namespace this also appears to me to be irrelevant.
to maintain compatibility between namespace aware and unaware parsers
this is necessary but not sufficient. also required is a standard
prefix.
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.
I take this to mean that you want separate namespaces for annotations and
sieve
proper. I'm against this because I dislike the complexity it adds, which I see
as unnecessary. And unless there's some evidence of support for your view from
other quarters I'm not going to revisit this.
without correct separation of concerns, the specification cannot be
used for generation. for developers working in modern langauges using
modern toolsets, this is a major limitation. it just means that
another standard will be required to support these use cases.
making support for annotations optional would be good enough for me.
ideally, i would like to see any mixture of XML allowed by the
specification. this would allow editors based on different principles
to claim support without having to adopt the recommended system of
annotations.
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.
I'm afraid I just don't see it. The pointers you have given so far have been
to
specifications I regard as overdesigned to the point of near unreadability.
in the xml community, these specifications are usually held in high
regard. it's just surprisingly hard to explain that it works just how
you'd hope it would.
- robert