perfsonar development work

[Roman Lapacz <>]

Jeff W. Boote wrote:
> Fausto Vetter wrote:
> > Hi,
> >
> > I wasnt saying to extend. I just wanted some semantics that would say:
> >
> > for eventType pingStore for example, there must be parameters of type 
> > nmwg and ping.
>
> To do what you are saying I would just have a single parameterS 
> element in the md using the pingStore namespace. It can have the full 
> set of parameter elements needed to fully describe the semantics.
>
> It is definitely possible to support groupings of parameters. Murilo's 
> example that we discussed last week already showed a parameterS 
> element as the value of a parameter. But, this is still a function of 
> the semantics of the single eventType defining what namespace is 
> expected for the outer parameterS element. (And what semantics are 
> expected.)

I'd like to start a new thread which focuses on complex structure of 
parameter.

I found this in the minutes from Brasil meeting:

   * Discussion was held on having complex parameters within message
     and support for a new namespace to include container structure.
     Two proposals with regard to TopS were sent to the mailing list
     some time ago: one from MV with nested parameters and then its
     modification done by RL. MS commented that MV's proposal is valid
     and we didn't need to use collection items as RL had suggested. He
     also added that Java code already supported what MV had suggested.
   * *Agreement*: MV's proposal accepted, RL's proposal rejected.



... and I found this example in one of the previous email (I believe it 
is what was agreed. If not then correct me.):


   <trans:parameters id="param3">
           <nmwg:parameter name="ConvertTo">unix</nmwg:parameter>
       <nmwg:parameter name="ConvertFrom">iso</nmwg:parameter>
       <nmwg:parameter name="ConvertElements">
           <trans:parameters id="cp1">
               <nmwg:parameter 
name="startTime">//nmwg:message//select:parameters/nmwg:parameter[@name="startTime"]</nmwg:parameter>
               <nmwg:parameter 
name="endTime">//nmwg:message//select:parameters/nmwg:parameter[@name="endTime"]</nmwg:parameter>
               <nmwg:parameter 
name="datumTimeValue">//nmwg:message//nmwg:data/nmwg:datum[@timeType!="iso"]</nmwg:parameter>
           </trans:parameters>
       </nmwg:parameter>
   </trans:parameters>



My comments:

- Creating hierarchical structures using the same names looks not 
natural to me. I understand that the implementation is already prepared 
for such solution and adding new names/elements to the schema increases 
a quite big number of existing elements but presented xml structure may 
look strange and unclear for others.

- I think we should prepare parameter element to contain ordered list of 
values (for now I don't have an example when we could use it but at 
least we would be ready to support it). Introducing types of collection 
that I described in my proposal solves this issue (I'm not stuck to used 
names).


Roman




> In Murilo's example, the inner parameterS will be defined by the 
> semantics of the eventType as well because the code that reads the 
> parameters will be expecting to handle a parameter with a value of 
> this complex type.
>
> I believe all of this is already currently supported. I'm saying I 
> don't see a need to change anything to represent these relationships. 
> (By adding some new kind of mapping in the general nmwg eventType -> 
> parameters mapping.)
>
> jeff