To finally weigh in on this...
> > 1. A single (flat) diagnostic namespace as now, and include any and
> > all offending diagnostics.
> I agree with those who have already eloquently argued against this
Agreed.
> > 2. A flat diagnostic namespace, partitioned, with offending
> > diagnostics not in the "general" partition. Perhaps two partitions,
> > general and private; perhaps additional partitions.
> This is not a solution any more, if it ever was. In an information
Agreed. Two independant entities can define diagnostic 5000, making both
useless.
> > 3. Define a diagnostic object type, and include it in the diagnostic
> > schema.
So a diagnostic would be a record with a recordSchema. I don't think that
this is useful either -- we need a single way to deal with all errors. It
doesn't really solve the problem of being able to create new, profiled,
errors.
It's much the same as 5, in that respect.
> > 4. Define a diagnostic object type, and a diagnostic url which
> > includes the diagnostic object type, and change the diagnostic
> > schema so that a diagnostic uri is supplied instead of an integer.
I think that this is the solution, along with the requirement that
diagnostics which are not part of the official list can only be returned
in response to a client's extension request.
This is also easy to implement -- change the diagnostic/code type to
anyUri and assign info:srw/diagnostic/1/<number> to all of the current
diagnostics.
> > 5. Assume that all offending or strange diagnostics are associated
> > with an extension, so return the diagnostic qualified by the
> > extension id.
This would require adding a new field to diagnostic, just to qualify the
integer. It seems more correct to just change integer to a URI.
Rob
--
,'/:. Dr Robert Sanderson ([log in to unmask])
,'-/::::. http://www.o-r-g.org/~azaroth/
,'--/::(@)::. Special Collections and Archives, extension 3142
,'---/::::::::::. Nebmedes: http://nebmedes.o-r-g.org:8000/
____/:::::::::::::.
I L L U M I N A T I
|