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


_______________________________________________
Nmc-wg mailing list
Nmc-wg@ogf.org
http://www.ogf.org/mailman/listinfo/nmc-wg