perfsonar development work

["Jeff W. Boote" <>]

Roman Lapacz wrote:
> > The problem is that there are multiple levels of information that need 
> > to be communicated, and they are not being adequately communicated. 
> > Only one of those things is 'schema' (or schema version).
>
> Generally I agree what you wrote in attached message about using 
> eventType as an indicator of schema version. But I also understand that 
> the version number of schema is also included in the namaspace of each 
> element used in a message. Examples:
>
> version 2.0:  http://ggf.org/ns/nmwg/base/2.0/subject/
> version 2.0:  
> http://ggf.org/ns/nmwg/characteristic/utilization/2.0/subject/
> version 1.0:  
> http://ggf.org/ns/nmwg/tools/org/perfsonar/service/1.0/contactEmail/
> version 3.0:  http://ggf.org/ns/nmwg/topology/base/3.0/interface/
>
> Currently it's possible to have elements of different schema versions in 
> one message but eventType element indicates just one version number.

The eventType uniquely defines the specific 'type' of data. The rest of the 
elements are absolutely completely defined by the version of the eventType. For 
example for eventType:
 http://ggf.org/ns/nmwg/characteristic/utilization/2.0

Only specific versions of the topology schema elements are supported. If you 
want to use different topology elements, you would bump the utilization version 
to indicate that. Likewise, adding or changing parameters would require a change 
in the eventType version.

> > The others are protocol and profile. (See attached message.)
> >
> > I'm not convinced that a message-parameter is really enough here for 
> > the 'general' solution. I suspect we may want this information 
> > published to the LS somehow as well. But, I guess something like this 
> > would at least be a start.
>
> I agree that the LS should contain also protocol versions used by 
> registered services. Your proposal of using parameter right under 
> message element is fine but we might need better solution if we have 
> more data triggers (logical sub-requests) in one message. Then we might 
> want, because of some reasons, different protocol versions for those 
> sub-requests. The solution might be putting protocol version directly 
> in/under data trigger element. Example:

I think this complicates things too much. A message should only be from a single 
protocol. If a client for some reason wants to make a request with two different 
versions of the protocol, it can make two distinct connections/requests.

jeff