Re: draft-freed-sieve-in-xml status?

[Ned Freed <[e-mail]>]

> On Sun, Dec 14, 2008 at 5:46 PM, Ned Freed <[e-mail]> wrote:
> >> 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.

And by the same token, those that don't support namespaces (and there's
lots of XML stuff out there that doesn't), will have trouble.

I think this is a wash.

> this makes the standard much less generally useful than it might be
> otherwise.

I disagree. I think yoy're making a mountain out of, at best, a molehill.

> >> 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
> editors.

That may be your opinion. i quite simply disagree.

> >> i also note that there is no separate of concerns between the editor
> >> annotations and the substantive xml. could anyone explain this design
> >> decision?
> >
> > Because it would add unnecessary complexity to the design. The implication that
> > 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?

Nope.

				Ned