Fwd: ISSUE: Naming of error object encoding

[Mark Taylor]

On Thu, 1 May 2008, Mike Fitzpatrick wrote:

>> I'm not necessarily against supplying a status in message responses;
>> a "status" (or "error.status" or "samp.error.status" or whatever)
>> key could be added to those suggested above and could take values
>> such as "error", "warning" and others from a well-known vocabulary
>> which we supply, possibly allowing users to extend it for their own
>> purposes.
>
>    The problem here is that we're then defining a separate vocabulary for a
> Response
> than we are for Message MTypes.

to me, that doesn't sound like a problem, because they are doing 
different jobs.  I would say that separate namespaces for separate 
purposes is good design.

> I'm already worried that we're confusing
> things
> to have a 'samp.hub.method' in the XML-RPC profile, a 'samp.secret' in the
> lockfile
> metadata, a 'file.load' as a MType and now a 'status.warning' in a Response
> status
> keyword.  The 'word.word' syntax is too overloaded with meaning.
>
> ...
>
>> as I said above, by all means propose some key for a non-free-form,
>> parsable value, and values it can take, to go along with the others proposed
>> for the error response map.
>
>    As i say above, any such key would be a separate vocabulary and further
> overload
> the 'word.word' syntax we use for MTypes, metadata namespaces, method names,
> .....

Yes it would.  As long as the document clearly describes where each
separate vocabulary is to be used, I don't see any disadvantage in
having as many separate vocabularies as we need.  Indeed I think it's
much better than using the same vocabulary for several semantically
distinct purposes.  I don't have a computer science reference for that,
but it seems to me like an obvious principle of good design.  Do we
actually disagree about this?

-- 
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b.taylor at bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/