(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.
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.
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.
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.
Ned