[Nmc-wg] Base doc

[Roman Lapacz]

Jason Zurawski wrote:
>
>
> 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

OK, now I see. So just the reference to namespace description is enough.
Comparing those two docs I think we could describe xml elements the same 
way (now, one doc uses tables, the other one uses simple lists).

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

I'll take a close look here.

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

Agree. Main description in NM-WG doc and only the reference to it in 
NMC-WG doc (with some additional information related with NMC).
This way we'll keep consistency. Now I see two names for the same thing: 
operation chaining (NM-WG doc) and filter chaining (NMC-WG doc).

I'm also thinking that maybe filer chaining fits better into NMC-WG (it 
deals more with action than data/metadata representation).

>
>
>
>> - 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 would clean it.


Roman