Mappings: old result codes -> new result codes
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
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. 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
_______________________________________________ Nmc-wg mailing list Nmc-wg@ogf.org http://www.ogf.org/mailman/listinfo/nmc-wg
ESCC/Internet2 Joint Techs July 11-15, 2010 - Columbus, Ohio http://events.internet2.edu/2010/jt-oarnet/
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
_______________________________________________ Nmc-wg mailing list Nmc-wg@ogf.org http://www.ogf.org/mailman/listinfo/nmc-wg ESCC/Internet2 Joint Techs July 11-15, 2010 - Columbus, Ohio http://events.internet2.edu/2010/jt-oarnet/
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
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@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
Hi Roman; I have added these to the wiki, we can discuss them today. -jason On 9/30/10 8:45 AM, Roman Łapacz wrote:
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@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
Hi Roman; Here are some additional comments to back up what we discussed on the call: On 9/30/10 8:45 AM, Roman Łapacz wrote:
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.
So the example I had in mind was something like this: <message> <metadata id="m1"> <!-- ... something ... --> </metadat> <data id="d1" metadataIdRef="m1" /> <metadata id="m2"> <!-- ... something ... --> </metadat> <!-- no trigger for m2, and m2 is not related to m1 or d1 --> </message> In this case m1 and d1 could be acted on, and m2 could not (it would get the error.ls_data_trigger response). The pSPS would return the results for the first metadata/data pair and an error for the second in the same message. My objection is related to the proposed "http://perfsonar.net/status/clienterror/wrong_message_structure/" eventType. In this case the message structure is syntactically correct, the semantics are just wrong in one instance.
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).
I forget what the outcome of the early discussion was (I am sure someone can correct me), but I believe that the description that will be returned in the datum does not need to be a 'standard' message. The eventType code and instructions guiding its use (e.g. 'use this this code for errors that are related to ...') are the only thing we should make standard. If someone wants to send back a datum that contains more than what the standard definition allows (e.g. a stack trace perhaps, or error logs) this seems fine to me.
"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).
I dont think we should be assuming a default message type, because what would be the default? Services like the LS use different messages than the MAs and MPs. I would still favor having both 'type unsupported' and 'no 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.
Doesn't message_element_not_supported match here?
Good question. I guess I can see this happening in one of two ways:
1) the element is unexpected semantically, but still schematically
legal. For example:
ns1:metadata
Roman
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
Hi Jason, On Fri, 1 Oct 2010, Jason Zurawski wrote:
Hi Roman;
Here are some additional comments to back up what we discussed on the call:
On 9/30/10 8:45 AM, Roman Łapacz wrote:
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.
So the example I had in mind was something like this:
<message> <metadata id="m1"> <!-- ... something ... --> </metadat> <data id="d1" metadataIdRef="m1" />
<metadata id="m2"> <!-- ... something ... --> </metadat>
<!-- no trigger for m2, and m2 is not related to m1 or d1 --> </message>
In this case m1 and d1 could be acted on, and m2 could not (it would get the error.ls_data_trigger response). The pSPS would return the results for the first metadata/data pair and an error for the second in the same message.
Geant MA services with base1 library were able to accept such messages. Services with base2 probably are able as well but I don't remember it in 100%. In general for me a message with more than one data triggers contains logical separate messages which should be processed independently.
My objection is related to the proposed "http://perfsonar.net/status/clienterror/wrong_message_structure/" eventType. In this case the message structure is syntactically correct, the semantics are just wrong in one instance.
First chain in the example is correct and the response should contain some data. The metadata m2 is hanging and it may be difficult to figure out by a service is it a part of functional chaining (so somehow connected with metadata m1) or is data trigger d2 missing. Proposed event type name is incorrect but more general one, e.g. http://perfsonar.net/status/clienterror/wrong_structure/ may be suitable. <message> <metadata id="m1"> <!-- ... --> </metadata> <data id="d1" metadataIdRef="m1"> <!-- ... --> </data> <metadata id="m2"> <!-- http://perfsonar.net/status/clienterror/wrong_structure/ --> <!-- for hanging m2 --> </metadata> <data id="d2" metadataIdRef="m2"> <!-- datum with some explanation --> </data> </message> Even we could ignore m2 because it does not belong to any chain in the message.
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).
I forget what the outcome of the early discussion was (I am sure someone can correct me), but I believe that the description that will be returned in the datum does not need to be a 'standard' message. The eventType code and instructions guiding its use (e.g. 'use this this code for errors that are related to ...') are the only thing we should make standard. If someone wants to send back a datum that contains more than what the standard definition allows (e.g. a stack trace perhaps, or error logs) this seems fine to me.
Agree.
"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).
I dont think we should be assuming a default message type, because what would be the default? Services like the LS use different messages than the MAs and MPs. I would still favor having both 'type unsupported' and 'no type specified'.
OK. That sounds reasonable. (I was thinking that each service could have such default message type depending on service type but that would fail if an implementation represented two service types)
"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?
Good question. I guess I can see this happening in one of two ways:
1) the element is unexpected semantically, but still schematically legal. For example:
2) The element is not semantically or schematically expected. For example
I would say these are different errors. In #1 the parser may choose to interpret the 'last' parameters element it saw, so things may still 'work'. We may owe the user a warning to say that something didnt look right though. In #2 the element is unexpected and may be no-recoverable from a parsing standpoint.
So we have two groups of errors: semantic and structural. The HTTP style of grouping does not show it but maybe it would be useful. Roman
Hope this helps;
-jason
Roman
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
participants (5)
-
Aaron Brown
-
Jason Zurawski
-
Roman Lapacz
-
Roman Łapacz
-
romradz@man.poznan.pl