[Nmc-wg] Base doc

[Jason Zurawski]

Proposal 3 seems to be the favorite from the pS-dev mailing list.  I 
like it too, but have the following comments/concerns:

  - The structure is a bit more rigid than the others, e.g. this is 
something that we (perfsonar/nmc) would set in stone instead of our 
normal 'living document' approach.  This is not a bad thing, but there 
is a bit more wiggle room in the other approaches; a developer could 
carve out new space under /ma or similar for new service types without 
needing to upset the specification.

I think the approach in proposal 3 would force compatibility quickly, 
but it also puts a lot of pressure to 'get it right' the first time. 
This group should carefully consider the categories and try to 
anticipate all of the needs as we make the recommendation.

  - Jeff/Roman/Myself had started a mini discussion on the merits of 
clients needing vs wanting to know more about an error, e.g. an error is 
an error regardless of where it comes from (an mp or an ma).  I am still 
not completely convinced this is always be the case, I think knowledge 
regarding the service type in particular is valuable.

The compromise here is was to introduce parameters to the result code 
message to convey this information making smart and dumb clients happy.

  - The document should explain that the eventTypes are set in the 
stone, and a default message should be described for each as well.  It 
seems reasonable to allows services to modify this message if desired, 
as long as the eventTypes are respected.

Thanks;

-jason



> Thanks Slawomir.
> 
> It would be great if people could either respond to this thread with 
> their opinions on the proposed solutions, or be on the call/VC so we can 
> come to some resolution on this topic.
> 
> thanks,
> jeff
> 
> On Jan 12, 2010, at 2:58 AM, Slawomir Trzaszczka wrote:
> 
>> Hi all,
>>
>>
>> On Mon, 2010-01-11 at 20:01 -0500, Jason Zurawski wrote:
>>> Hi Roman;
>>>
>>> Thanks for the feedback, comments inline:
>>>
>>>
>>>> some first comments/observations:
>>>>
>>>> - I think the structure of namespace could be explained
>>>
>>>
>>> The original thinking was the NM-WG document, "An Extensible Schema for
>>> Network Measurement and Performance Data", would contain the entire
>>> explanation of namespaces (the idea itself coming from another OGF WG).
>>>    Any future documents from related projects (NMC, NML, others?) would
>>> reference this and only note caveats to the original rule.  The NM-WG
>>> doc is here:
>>>
>>> https://forge.gridforum.org/sf/go/doc15649?nav=1
>>>
>>> And I think namespaces are in section 4.  Does everyone think this is
>>> sufficient, or should we consider other options?
>>>
>>>
>>>> - example of status response in 4.1 does not explain too much (looks 
>>>> the
>>>> same as earlier response example)
>>>
>>>
>>> Now that things are in SVN, could you suggest a more fitting example?
>>>
>>>
>>>> - in 4.3.2.6 the concept of key could be explained more (for me the key
>>>> represents some bigger information structure; reasons: performance,
>>>> simplicity)
>>>
>>>
>>> Good ideas, I will note these.
>>>
>>>
>>>> - in 4.3.2.7 the reference to "Characteristic" document is missing
>>>
>>>
>>> Good catch, I will add a real reference.
>>>
>>>
>>>> - I'm wondering whether we can say in 4.3.3 that the request with more
>>>> data triggers includes logical independent sub-requests
>>>
>>>
>>> The concept of chaining is also something that Martin and I have
>>> struggled to find a proper location.  Chaining is explained in sections
>>> 5 and 6 of the above NM-WG document currently.  I think the basics
>>> should remain in NM-WG since the concept of the chain is essential to
>>> the definition of data and metadata.  We may be able to reference the
>>> basic concept though to motivate some of the more unique cases.
>>>
>>>
>>>> - 4.4.1: typo "request schema"
>>>
>>>
>>> I will correct.
>>>
>>>
>>>> - I would remove parameter elements "supportedEventType" from all
>>>> message examples. I understand that it's supported by the
>>>> implementations but it's agreed to use eventType element
>>>
>>>
>>> I don't think this is a big deal, since these are just examples.  I can
>>> remove them if we think it will cause confusion.
>>>
>>>
>>>> - I think we have to rebuild Result Code section and finish the
>>>> discussion on new ideas proposed by Slawek and Jeff. That's very
>>>> important and must be done.
>>>
>>>
>>> This would be the current venu to do so.  Has Slawek updated his
>>> document based on the suggestions that were made before the holidays?
>>> Perhaps he can send it again?
>>
>> Yes,
>> file is in attachment
>>
>> Regards,
>>
>> Slawek