On Sun, Dec 14, 2008 at 6:06 PM, Ned Freed
<ned(_dot_)freed(_at_)mrochek(_dot_)com> wrote:
i note that the draft describes the infoset rather than defining it in
the standard way. is there a reason for this decision?
I don't know what "the standard way" is you're referring to. Perhaps you
could provide a reference to an RFC where this has been used?
AIUI XML is maintained by w3c (rather than IEFT) so is a
recommendation. http://www.w3.org/TR/xml-infoset/ is the current
document.
This document is a little unusual in that it's defining a mapping of, if you
will, a non-XML infoset onto XML. As such, the natural approach seemed to be
to
first discuss the structure of the language being mapped, then explain the
mapping, and finish up with additional unique-to-XML semantics.
i agree that most of this arangement is natural. it's just jumping to
a schema seems - to me - a little premature and inflexible.
This approach is perhaps not the best choice for someone coming at this trying
to get at Sieve semantics starting with XML, but I believe consumers of the
document with that mindset will be distinctly in the minority. The main focus
here is to provide people familiar with Sieve a means of mapping Sieve to XML
so that XML tools can be applied.
my experience is entirely opposite
developers that use the java libraries i work on have good XML but
lack a good understanding of underlying mail technologies (for example
sieve). there is a large and growing requirement for integration
between mail and enterprise systems (typically coding in Java and .NET
but also ruby and python). developers from enterprise backgrounds are
typically strong on web+xml but very weak on mail.
i think that there needs to be an equal focus should be on allowing
mainstream enterprise developers familar with XML and web technologies
to apply familiar methods and techniques to mail. this will allow
easier and more efficient editor development.
FWIW i think that the draft works quite well from this perspective but
an annotated schema with an appropriate open source (eg MIT) license
would be very useful way of introducing developers to Sieve.
Had this been the more usual case of simply defining an XML formal, I have to
admit that I would have gone with the informal approach used in, say, RFC
2629.
I'm not all that keen on lots of formalism - IMO it often hinders
understanding more than it helps.
IMHO the problem is getting the right level of formalism
more modern approaches to specification (eg Atom
http://www.rfc-editor.org/rfc/rfc5023.txt etc) tend to make the schema
only informative and the description of the infoset normative. this
would be more flexible for example, by allowing different schema
langauges to be used, alterations in namespace or additional
annotations in foreign vocabularies.
- robert