perfsonar development work

[Roman Łapacz <>]

Roman Lapacz napisał(a):
> Jeff W. Boote wrote:
> > 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?)
>
> hmm, 'parameter' inside 'parameter' does not look like a natural xml 
> structure, this is my strong feeling
>
> > > - 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.
>
> But what if you have two parameterS blocks (one ordered and the second 
> one not). You can not assign eventType to one of them. Maybe it's not 
> a problem to treat parameters which are not ordered as ordered but the 
> idea of use eventType here does not fit.
but we said that the metadata element will contain only one parameterS 
block (the key may have multiple parameterS elements) so there is no 
problem mentioned by me in the sentence above.

Roman