Hi Roman; Thanks for doing this, I will try to send an updated version by the end of the week, and include this in the formal document. Thanks; -jason On 9/27/11 12:32 PM, thus spake Roman Łapacz:
W dniu 2011-09-23 14:22, Jason Zurawski pisze:
Hi Roman;
I think this is a good idea, would you be able to make the changes to the document and sent it back to the list?
Attached (needs polishing).
Cheers, Roman
Thanks;
-jason
On 9/23/11 12:29 PM, thus spake Roman Łapacz:
W dniu 2011-09-23 11:32, Jason Zurawski pisze:
Gang;
Hi,
In typing up the final version of the status codes into the document, I hit upon a snag. Here is an example of what was proposed in the prior mail:
http://schemas.ogf.org/nmc/2011/09/status/informational/protocol version/
This goes against our typical method of constructing namespaces. I would suggest we do this instead:
http://schemas.ogf.org/nmc/status/informational/protocol version/2011/09/
Or even better using:
201109
or
20110923
Right. Good you spotted this. I prefer to have just one field for version number (201109 or 20110923) with an exception for early testing versions (201109/beta or 20110923/beta).
As the 'version' string. I am attaching an updated document going with the first suggestion, I prefer the last best of all. Other opinions?
What do you think to replace the code hierarchy with the pattern in the beginning of section 2. Example:
--example---------------------
"http://schemas.ogf.org/nmc/status/"<STATUS_CATEGORY>"/"<STATUS_NAME>"/"<VERSION>
<STATUS_CATEGORY> may have the following text values: - informational - successful - redirection - clienterror - servererror
<STATUS_NAME> depends on the status category and may have the following text values: - informational category -- protocol version -- data limitation -- service_contact - client error category -- bad_message -- bad request -- authentication_failed -- unauthorized -- message not allowed -- event_type_not_allowed -- event_type_not_allowed -- request_too_large -- request_timeout -- protocol_not_allowed -- chaining_not_understood - servererror category -- data_fetch_error -- too_busy -- administrative_down Two categories, successful and redirection, do not need to have certain status names.
VERSION is a string presenting information about the version of protocol, e.g. 201109 or 20110925. In case of early testing version an optional part after "/" may be added (e.g. 201109/beta or 20110925/beta) .
-- end---------------------
I'm thinking about such update because version numbers don't look good in the structure. They are not generic. The use of pattern solves this issue. What do you think? (of course a short description below the pattern in my example may be done much better; I just wanted to present my idea).
Cheers, Roman
Thanks;
-jason