On Sun, Dec 14, 2008 at 5:46 PM, Ned Freed
i note that the xml lacks a namespace.
Yes, but AFAIK nothing prevents you from assigning this vocabulary to a
namespace if you wanted to mix it with some other vocabulary. But since
the need for such mixing doesn't arise in the document itself, why
bother with the added complexity?
by specifying the default namespace, any GUIs who require namespace
support must deviate from the standard and maintain their own schema.
this makes the standard much less generally useful than it might be
could someone explain this design decision?
Well, I suppose this could have been done by having, say, one namespace for
Sieve stuff and another for annotations. But that adds a ton of complexity
with no real gains as far as I can see.
failing to separate these concerns makes the standard much less useful
for two broad classes of GUI - generative and web service backed
i also note that there is no separate of concerns between the editor
annotations and the substantive xml. could anyone explain this design
Because it would add unnecessary complexity to the design. The implication
editor annotations are insubstantive is also incorrect - in a GUI those
annotations are the focus and it's the Sieve content that's secondary.
i think this depends on the GUI. for generative approaches generally,
the annotations will need to be ignored.
were these annotations based on any existing standard?