perfsonar development work

[Roman Lapacz <>]

Jeff W. Boote wrote:
> > > <nmwg:message id="msg4"
> > >               
> > > type="http://schema.perfsonar.net/MessageTypes/SetupDataRequest/2.0";
> > >   
> >
> > This type is something new for me. We could consider changing 
> > existing names of message types.
>
> I do think we should consider it. (But, we should use the new OGF 
> standard for name-spaces instead of what I have here. Instead of the 
> version number, it uses a date-stamp.)

I'm open for such discussion. Later on we could consider improving the 
code responsible for taking the right message handler (I came across 
some limitations when I was implementing LookupInfoRequest) ... and 
later on replace simple property file with xml file for service 
configuration (sometimes nesting is needed).
> > - I don't like parameters inside parameter. Some time ago I proposed 
> > container structures in parameter (I asked Szymon to include it in 
> > the agenda for the meeting in Brazil)
>
> We did talk about it in the meeting. Consensus there was that there 
> was no need to add a special 'map' type given the fact that the 
> parameter list is already a map. We liked nested parameters. I suspect 
> this will be in Szymon's notes.

So Im' waiting for the minutes. Probably I will come back to this topic :)
> > So I could change your parameter this way
> >
> > <trans:parameters id="param3">
> >
> >  <!-- other parameters -->
> >  <!--  ...  -->
> >
> >  <list:parameter name="ConvertElements">
> >      <collection:item name 
> > name="startTime">//nmwg:message//select:parameters/nmwg:parameter[@name="startTime"]</collection:item> 
> >
> >      <collection:item 
> > name="endTime">//nmwg:message//select:parameters/nmwg:parameter[@name="endTime"]</collection:item> 
> >
> >      <collection:item 
> > name="datumTimeValue">//nmwg:message//nmwg:data/nmwg:datum[@timeType!="iso"]</collection:item> 
> >
> >  </list:parameter>
> >
> > </trans:parameters>
> >
> >
> > I think this solution could be very useful also in other messages.
>
> So, you keep the XPath? Ok.

Yes. I'm not against. I just think that we should be careful because 1) 
we need simplicity (using xpath in messages might be difficult for 
others) 2) and prepare for questions that most of contents of our 
metadata elements (those for searching in the metadata configuration) in 
requests could be replaced by xpath or xquery statements.


> >   <!-- The third metadata is used to convert the results of the first
> >   operation. -->
> >   <nmwg:metadata id="meta3">
> >
> >     <timetrans:subject id="iusub3" metadataIdRef="meta2"/>
> >
> >     <timetrans:parameters id="param3">
> >       <nmwg:parameter name="ConvertTo">unix</nmwg:parameter>
> >       <nmwg:parameter name="ConvertFrom">iso</nmwg:parameter>
> >     </timetrans:parameters>
> >
> >     
> > <nmwg:eventType>http://schema.perfsonar.net/tools/transform/time/2.0</nmwg:eventType> 
>
> You have a 'generic' eventType here, but no parameters listed to show 
> you which elements to change. Remember, this transformation could be 
> implemented in a completely different transformation service that 
> might not know anything about the specific data type represented by 
> the 'utilization' namespace. That is why I had the XPath in the 
> parameters so the client could indicate exactly what they wanted 
> converted.
>
> As I said in my previous message - if you want one specifically tied 
> to the utilization namespace, then it could of course be much simpler. 
> (like this) But, if you do that - I think the eventType needs to be 
> something related to the utilization namespace:
>
> http://schema.perfonar.net/tools/transform/utilization/unixtime/2.0

I see your point (you a right to change the namespace). I think we can 
accept both approaches (at least for now as we don't have any experience 
using them). The second one seems to be simpler (and probably faster if 
you don't have to use xpath engine). The first one is more general. Are 
you OK to support both?


Roman