perfsonar development work

[Roman <>]

Jason Zurawski wrote:
> All;
>
> In relation to the discussions today in Berlin, it was decided that 
> this would be more appropriate (note the lack of the 'type' attribute 
> in the parameter element):
>
>
> <nmwg:metadata id="meta1">
>     <netutil:subject id="subj1">
>         <nmwgt:interface>
>             <!-- ... some interface elements -->
>         </nmwgt:interface>
>      </netutil:subject>
>      
> <nmwg:eventType>http://ggf.org/ns/nmwg/characteristic/utilization/2.0</nmwg:eventType> 
>
>      <nmwg:parameters>
>          <nmwg:parameter 
> name="keyword">http://geant2.net</nmwg:parameter>

Just one comment: type attribute could be convenient for filtering 
(useful for categorizing keywords).

Roman

>      </nmwg:parameters>
> </nmwg:metadata>
>
>
> Will someone check to be sure the necessary changes to the 
> requirements document are completed?
>
> -jason
>
>
> > Hi Jeff and Roman,
> >
> > The change specs have been updated according to your suggestions. I 
> > have removed the inheritance bit (its a nice-to-have rather than a 
> > must-have, better to leave it out for now).
> >
> > Loukik
> >
> >
> >
> > Roman Lapacz wrote:
> > > Jeff W. Boote wrote:
> > > > Hi Loukik,
> > > >
> > > > I'm sorry, but I do have a problem with the way you put the keyword 
> > > > parameter in here.
> > > >
> > > > This is not what I understood from the previous interaction. I 
> > > > thought you were going to use the parameters from the metadata, not 
> > > > modify the topology elements to add a parameters block in. (I 
> > > > thought the main point of using parameters was that schema 
> > > > definitions would not have to change. The way you have done this 
> > > > would modify the parsing in the Java implementation as well...) If 
> > > > we are actually going to modify schema, I would advocate a full 
> > > > fledged element for this functionality - I do not think an 
> > > > amorphous parameters block is a good idea 'inside' the topology 
> > > > schema elements. That will make several other things we need to do 
> > > > more difficult (summarization/topology sharing/etc...).
> > > >
> > > > Also - just a comment based on reading this - I think adding this 
> > > > parameter into the top of your store file is likely a mistake. I 
> > > > don't have a strong opinion about it since the store file is 
> > > > internal to your services and does not impact protocol or 
> > > > interoperability. But, you should think about this because I think 
> > > > it will present some special case situations that will likely make 
> > > > ongoing maintenance of those services more difficult. (i.e. are all 
> > > > parameters from this location subject to this 'inheritance' to 
> > > > internal param blocks? There are parameters at different levels of 
> > > > the schema, which ones does this inheritance apply to?)
> > >
> > > I agree with Jeff. My understanding of using new parameter 'keyword' 
> > > is that it will be used like other parameters in metadata block:
> > >
> > >
> > >  <nmwg:metadata id="meta1">
> > >      <netutil:subject id="subj1">
> > >          <nmwgt:interface>
> > >              <!-- ... some interface elements -->
> > >          </nmwgt:interface>
> > >       </netutil:subject>
> > >       
> > > <nmwg:eventType>http://ggf.org/ns/nmwg/characteristic/utilization/2.0</nmwg:eventType> 
> > >
> > >       <nmwg:parameters>
> > >           <nmwg:parameter name="keyword" 
> > > type="project">http://geant2.net</nmwg:parameter>
> > >       </nmwg:parameters>
> > >  </nmwg:metadata>
> > >
> > >
> > >
> > > I also suggest to use this parameter only inside metadata block.