On Thu, Jan 8, 2009 at 4:27 PM, Ned Freed
<ned(_dot_)freed(_at_)mrochek(_dot_)com> wrote:
however (in my experience) the generative tools commonly used for XML
and web service binding, and editor generation tend not to offer good
relax support. IMO the draft should offer secondary informative XML
Schema or Schemata to assist developers using these tools.
The problem is that the unique particle attribution limitation in XML
Schema
effectively precludes using it without some compromises. I am therefore
opposed
to continuing to include it.
adopting a standard prefix - sieve, say - is all that is required
To get around the unique particle attribution restriction that prevents XML
Schema from describing many legitimate schemata? If that's truly the case a
lot
of XML developers would love to hear more.
is this really too much to ask?
I fail to see what defining a prefix has to do with the use or non-use of XML
Schema, but for about the tenth time, I have already added a namespace name
registration to the specification.
AFAIK the specific namespace prefix that gets bound to the namespace name is
not something that can or should be standardized. Rather, it is declared on a
per-document basis using an xmlns attribute. Any agent out there that supports
namespaces should support the use of xmlns to pick whatever prefix a given
document binds to the urn:ietf:params:xml:sieve namespace.
this choice of namespace prefix is the root cause of incompatibility
between namespace aware and unaware parsers
for example, 'sieve:abc' is just a name to unaware parsers while aware
parsers understand this as a namespace prefix and a local part. the
namespace prefix is resolved to a URI and that is used as the basis of
comparison. specifing a standard prefix (for example, sieve) ensures
that in both cases equality works as expected.
<snip>
for the class of application (enterprise mail servers is a name that's
sometimes used but quite possibly that's not familiar to others in the
group), unfortunately it is
Robert, developing enterprise and ISP class mail servers is what I do for a
living. I've been doing it for over 20 years now. So I think this is something
I might know just a little bit about.
i am not unaware of your background but i fail to see why i should
respect your arguments when you are so clearly uninformed about a
class of mail server which are almost a decade old now
But really, this entire discussion has gone very far afield. Like it or not,
Sieve is intended to be a language used to process email messages at or around
the time of final delivery.
The fact that it can be adapted for other uses may
be interesting to you but simply is not relevant in the context of the work
this group is chartered to do.
is this http://www.ietf.org/html.charters/sieve-charter.html the charter?
- robert