perfsonar development work

[Roman Lapacz <>]

Jeff W. Boote wrote:
> Roman Lapacz wrote:
> > OK. So we can say that using multiple parameters elements in cases 
> > described is clarified and agreed. If there will be no objections 
> > from others I think we can add this to TODO list for the schema. Is 
> > it OK?
>
> Ok, let me try and give a more verbose description to the problem I 
> see. (Sorry, I'm just getting my first cup of coffee this morning and 
> I can now see I did not really explain myself very well in the 
> previous message.)
>
> First of all, I'm fine with multiple parameters blocks inside a 'key'. 
> (Key's are supposed to be opaque, so as far as I'm concerned a service 
> can put whatever they want inside them. Clients should not be looking 
> inside anyway.)
>
> But, I am not ok with multiple parameters blocks inside 'metadata'. 
> So, I will try and explain myself more clearly for this part:

From the beginning of this discussion I've had in mind mainly the key 
element as a container for multiple parameterS elements. I was 
mentioning about the metadata because I thought it was also possible 
place to contain multiple parameterS elements but you right that 
function-chining is the solution for the metadata.
So I propose to stay with only the key as the right case of using 
multiple parameterS elements.

> We want to make sure our schema supports applications that can be 
> dynamically extended. That way plugins can be used to extend their 
> functionality. So, I'm thinking about this in the context of 
> dynamically loading logic to support eventTypes.
>
> Currently, it is possible to dynamically load objects to handle the 
> semantics of a specific type of metadata based on the eventType. 
> Essentially, the eventType defines a specific 'function' or 
> 'semantics' that works with a specific set of parameters. If we 
> dynamically load an object to handle this logic, it can know which 
> parameter elements are expected and dependent on which other parameter 
> elements.
>
> You only get one eventType in the metadata, and the value of that 
> eventType is supposed to match the namespace of the parameters 
> element. If we allowed multiple parameters, this mapping breaks.

I agree with you and now I see that adding the metadata do the 
discussion introduced unnecessary confusion. In fact, I was always 
thinking of the key here.
> This makes dynamic loading more complicated.

I like the idea of loading. But when a service must first create a key 
loading will probably not be used (at least for original request). This 
is because creating a key is just transforming original request into key 
representation which loses original shape (metadata elements with 
eventTypes chained in function way). And then using the key a real 
action is done inside a service.


Roman

> I'm not sure what example I could give to explain this... It is not 
> really an issue with the syntax of the XML, it is an issue of how that 
> syntax facilitates clients and services.
>
> Hopefully I'm awake enough to make more sense this time. ;)
>
> jeff