perfsonar development work

[Fausto Vetter <>]

Hi,

For this eventType matching issue issue, here goes 3 proposals:

1) map event type mapping to a specific set of parameters:

Ex:
eventType1 --maps--> parametersA AND parameterB
eventType2 --maps--> parametersC OR parameterD
eventType3 --maps--> parametersA(parametersC OR parameterD) AND 
parameterB(parametersC AND parameterD)

2) have parameters nested inside parameters (recursevely) and 
specifically to such types desired

Ex:
eventType1 --maps--> parametersA(parametersB(parametersC))

3) have 2 metadata sections to represent it.

Ex:
metadata1 (eventType1 --maps--> parametersA)
metadata2 refid metadata1 (eventType2 --maps--> parametersB)

Fausto

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:
>
> 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.
>
> This makes dynamic loading more complicated.
>
> 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