perfsonar development work

["Jeff W. Boote" <>]

So, what is the motivation for removing the structure?

I personally think having good structure for the 'general' service descriptions 
is a very good thing. Especially when you consider the complexity parameters 
would add to xquery syntax clients would need to use to make queries of the LS.

Is the motivation that you don't want to add more ggf elements? If so, you might 
think about how this will effect your future DOM implementation. I suspect it 
complicates that.

Now, I do think that using parameters could be a useful way to add service 
specific information. i.e. Extra information a service might want to register 
about itself that does not fit in the structured lookup information. But, things 
that are useful for all services to register, should be done in a well 
structured way in my opinion.

jeff

Maciej Glowiak wrote:
> Hi,
>
> I think we could change current structure of Lookup Information:
>
> --------------------------------------------------------------
> <nmwg:metadata id="lookup-info">
>   <perfsonar:subject id="subj.15977808">
>       <psservice:service id="229.148.249.60.16283379">
>         <psservice:serviceName>Java RRD MA</psservice:serviceName>
>         <psservice:accessPoint>
>                     http://shower.fr:8080</psservice:accessPoint>
>         <psservice:serviceType>MA</psservice:serviceType>
>         <psservice:serviceDescription>
>                Java RRD MA, perfSONAR project, 229.148.249.60
>                </psservice:serviceDescription>
>       </psservice:service>
>   </perfsonar:subject>
> </nmwg:metadata>
> --------------------------------------------------------------
>
> to parametrized one:
>
> --------------------------------------------------------------
> <nmwg:metadata id="lookup-info">
>   <nmwg:parameters id="lookup-info">
>
>      <nmwg:parameter name="serviceName" value="Java RRD MA" />
>      <nmwg:parameter name="accessPoint" value="http://shower.fr:8080"; />
>      <nmwg:parameter name="serviceType" value="MA" />
>      <nmwg:parameter name="serviceDescription"
>            value="Java RRD MA, perfSONAR project, 229.148.249.60" />
>
>      <nmwg:parameters name="supportedEventTypes">
>          <nmwg:parameter name="eventType1"
>                          value="http://.../utilization/>
>          <nmwg:parameter name="eventType2"
>                          value="http://.../l2-path-status/>
>      </nmwg:parameters>
>
>   </nmwg:parameters>
> </nmwg:metadata>
> --------------------------------------------------------------
>
> As far as I remember we discussed it during one of our meetings, but 
> then it was just an idea.
>
> As you can see I added "supportedEventTypes" block, because it's quite 
> important to have such information in service metadata (requirement from 
> client apps). I used the schema of "supportedEventTypes" as agreed in 
> Brazil (or on the mailing list)
>
> The structure using "parameters" is more flexible, because service may 
> store any parameters it regards as important.
>
> We don't need to change anything in schemata, just to make some changes 
> in LS.
>
> What do you think?
>
> Maciej