perfsonar development work

[Roman Lapacz <>]

Jeff W. Boote wrote:
> Nicolas Simar wrote:
> > Hi,
Hi
> > I renamed this thread as it is not about schema version. I summarise 
> > the information seen on the mailing list.
> >
> > 1. What is the problem
> >
> > The schema (protocol?) evolves over time. The deployment of services 
> > by the networks operators don't always follow this evolution. The 
> > visualisation tools are ending-up having to deal with hard-coding a 
> > tool deployed and the schema used.
> > (Temporary measure exist to give some information through the URL, 
> > but not for all the services).
>
> It is not a problem that the schema evolves over time. It was designed 
> to evolve over time. This is a strength, not a problem. Otherwise, we 
> could have just as easily have used binary protocols for 
> client/service interactions. We picked XML specifically because we 
> wanted something extensible.
that's true
> 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 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:

<nmwg:message type="MetadataKeyRequest" .... >

 <nmwg:metadata id="meta1"> ... </nmwg:metadata>
 <nmwg:metadata id="meta2"> ... </nmwg:metadata>

 <nmwg:data id="data1" metadataIdRef="meta1">
   <nmwg:parameters>
     <nmwg:parameter name="pSprotocol">
       http://perfsonar.net/ns/protocol/MA/1.0
     </nmwg:parameter>
   </nmwg:parameters>
 </nmwg:data>

 <nmwg:data id="data2" metadataIdRef="meta2">
   <nmwg:parameters>
     <nmwg:parameter name="pSprotocol">
       http://perfsonar.net/ns/protocol/MA/1.1
     </nmwg:parameter>
   </nmwg:parameters>
 </nmwg:data>

</nmwg:message>



Roman