perfsonar development work

["Jeff W. Boote" <>]

Nina Jeliazkova wrote:
> Martin Swany написа:
> > Hi all,
> >
> > > From the point of view of client developer, services using "whatever
> > > they like" doesn't solve the problem, but on the contrary.  The client
> > > has to know the semantics of those strings, regardless of whether they
> > > have been received in datum entries or in metadata.  See my examples in
> > > previous mails. As I understood, Martin already agreed on this.
> > I do agree that there are many cases in which the client
> > needs to understand the units.  As I said, I'm concerned
> > about over-specifying things and making perfSONAR
> > difficult to extend.  But if one is using units that have been
> > previously used, then they need to use the agreed-upon
> > string.
> Under specifying might lead to heuristic solutions or wrong assumptions
> in clients, therefore I would prefer over specification rather than
> under specification, especially in a multi domain setting.
> Will be good if we could minimize the need of semantic interpretation
> and rely only on schema syntax, but not sure if this is possible.

I agree. This is really another side of the same coin with regard to things like 
'time types'. I just finished modifying the schema to strictly define the 'time 
types' that are known so that all clients/servers can easily determine the 
specific set in use. (Modified in a branch to support OWD schema work Verena and 
I have been doing. I will be merging it in to trunk later this week.)

It is much easier to relax things later if we want to, then to reign in lots of 
units/types if people start using many, many of them.

However, it should be noted that this will also lead to more changes in the 
schema over time. (We will certainly find additional units/'types' that we will 
want to add to the enumerations.) If we are going to so tightly couple these 
kinds of specifications into the schema, it MUST be recognized that these kinds 
of changes do not represent instability of the schema. I suspect that this is 
the reason Martin is not happy about over-specifying.

jeff