perfsonar development work

["Jeff W. Boote" <>]

Roman Lapacz wrote:
> I'd like to start a new thread which focuses on complex structure of 
> parameter.

Comments in-line.

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

I believe this is the fragment we actually used in the discussion:

<nmwg:metadata id="11">

   <nmwgtopo3:subject id="YYY">
   </nmwgtopo3:subject>
     
<nmwg:eventType>http://ggf.org/ns/nmwg/topology/actions/list</nmwg:eventType>
     <nmwgtopo3:parameters id="YYY">
       <nmwg:parameter name="include">
           <nmwg:parameter name="1">node</nmwg:parameter>
           <nmwg:parameter name="2">link</nmwg:parameter>
       </nmwg:parameter>
       <nmwg:parameter name="level">
           <nmwg:parameter name="1">detail</nmwg:parameter>
       </nmwg:parameter>
   </nmwgtopo3:parameters>

</nmwg:metadata>

(It is pretty much the same in this regard, but is perhaps not as confusing 
since the 'value' is not XPath...)

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

By same names, you are referring to the same element name? (Parameters?)

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

I can see the need for ordered list functionality, but not really the need for 
an element to support it. In Murlilo's example, he does not even use a container 
to hold the inner parameter elements. This is valid - and the semantics of his 
eventType can decide that the order of the inner parameter elements is 
meaningful. (And he easily could have defined new element types to use instead 
of parameter here - but parameter values can be anything that is recognized by 
the code that understands the given eventType.)

When someone creates a new eventType, and decides what parameter element 
names/values should be part of that, they can define the 'types' for the 
parameter values. So, anyone can create new element types to use in their 
extension. But, I agree that we want general things to be done the same way 
across multiple extensions. (Which I believe is your motivation for creating 
these container types?)

My proposal would be to keep things as they are currently, but to watch for 
potential common elements that would be useful as parameter values. (Like the 
nmtime elements.)

When we see new complex types that are created to be parameter values, we should 
move any of general interest into the 'base' nmwg to encourage reuse.

jeff