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.
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.
So, absent some fairly strong support for this from others in the group, I'm
not going to pursue this.
is there anyone else in group - excepting you and myself - who cares
enough to contribute at all to this discussion?
Well, quite a few people have cared enough to discuss other aspects of this
document in the past, and now that the topic of comment mapping has come
up a number are joining in again.
In other words, it seems people care about the document, just not about most of
the issues you have raised.
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.
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. I am therefore not going to continue to respond
further to this discussion of what applications developers do or do not need to
know about email and the specifics of header and envelpe handling. In fact I
regret having continued the discussion to this point.
Ned