[Nmc-wg] Mappings: old result codes -> new result codes

[Roman Łapacz]

  Hi Jason, Aaron and others,

I attached mapping text file and MS Word doc with small updates (just to 
have them together in one email).

W dniu 2010-05-27 21:08, Jason Zurawski pisze:
> 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).

If there is such data/metadata pair in a message than I wouldn't expect 
to get error.ls.data_trigger. An example of xml message would help to 
analyse such case.

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

I still have the problem how much context should be included in the code 
(mainly datum element contains a description).

>
> "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'

It just says ther's a problem with message type. Can we assume that if 
there's no message type then default type is considered (default type 
may be unspecified).

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

Doesn't message_element_not_supported match here?

Roman

>
> Thanks;
>
> -jason
>
>
> On 5/27/10 10:56 AM, romradz at 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>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ResultsCodes-20100930v1.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 25119 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/nmc-wg/attachments/20100930/8fa7b541/attachment-0001.bin 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: proposal-of-mappings-20100930v1.txt
Url: http://www.ogf.org/pipermail/nmc-wg/attachments/20100930/8fa7b541/attachment-0001.txt