Hi Roman/All; Some comments on the proposal: "Wrong structure of a request": Like Aaron, I think I am having a hard time with some of these as being a purely 'structural' issue. For instance 'error.ls.data_trigger' - I would assert there is some context to be known about the content of the rest of the message before calling this structural issue (for instance if there was a data/metadata pair already). I think most of these are right, but we should be careful with the context before calling all of them a pure xml structure violation. "EventType in a request is not supported": This also seems more context sensitive to me. "Request is not supported": I think 'message type unsupported' is different than 'no message type specified' "Elements of a request are not supported" I think we may need to be a bit more clear in the message. Instead of 'wrong XXX' we may want to say 'unexpected XXX element' or something similar. This will clear up of the content is wrong or the element is wrong. Thanks; -jason On 5/27/10 10:56 AM, romradz@man.poznan.pl wrote:
Hi Aron,
On Thu, 27 May 2010, Aaron Brown wrote:
One minor thing. I'd move the "No message type specified" to the "wrong_message_structure" since the request is missing a required element. I'm curious what the "message_element_not_supported" event type is for. From the error messages listed, It wasn't obvious to me why the service threw them.
for example, if an element located in a request is not recognized (or the content of xml tag is wrong, eg. ip address)
Roman
Cheers, Aaron
On May 27, 2010, at 10:32 AM, Roman Lapacz wrote:
Hi,
I've started preparing the mappings. So far I've focused only on RRD MA, PSPS commons and PSPS LS. This is just the beginning for the discussion (to check if this is a good direction for all interested).
Cheers, Roman <proposal-of-mappings-20100527v1.txt>