perfsonar development work

[Jason Zurawski <>]

Maciej;

> > So, what is the motivation for removing the structure?
> Motivation is:
>
> 1. Simplicity
>     - use of one tag (parameter) instead of many others (simper to
>       maintain)


It is true that this is simpler to maintain (never needing to add new 
elements) but at the same time you are losing all of the expressiveness 
and formality that has already been built in to the service 
description.  This description is very important to the framework since 
everything included is in fact a service, if for some reason the current 
description is not good enough we should work to make it better.  All 
services should use the same core set of items for a description, I 
don't see this list changing that often and if it does adding a new 
element would not become a chore. 

Using the generic approach in my opinion will open the door to allowing 
lots of differences in implementation which can complicate the handling 
of this new structure (such as deciding which of 'accessPoint', 
'access_point', and 'accesspoint' is acceptable, or adding new 'names' 
that may only be used by single services) where in the current design we 
do know what we are getting, and we know explicitly what everything means. 

The parameters approach was never meant to be a replacement for well 
defined descriptions in this protocol, it should be used in cases where 
there may be open questions of the data (i.e. using it to filter data).  
The only open questions that I think are being addressed by this 
approach is the use of 'supportEventTypes', which can of course be used 
in parameters to supplement the existing definition of the service 
description, not replace it outright.


>     - no need of schema and implementation modification to add new
>       parameters


There will not be schema modifications to add new elements when they are 
required in this case, but there most certainly be modifications that 
attempt to list the valid 'names' and their acceptable values/types.  If 
this is the case we are not really gaining anything. 


> 2. Flexibility
>     - adding new Lookup Info attributes for new services is easy
>       (because there is no need of schema and implementation changes)


This is a bit of a fallacy, no matter what 'new' things are decided upon 
to be added they still need to be documented and checked/handled in some 
way.  While we don't use validation currently of XML on deployed 
instances, it should be used sometime during the testing procedure.  All 
of the possible choices for these new parameters will need to be 
enumerated somewhere and in some form, whether its the current service 
description or the new way you are proposing.


> So, answering your questions:
>
> >
> > I personally think having good structure for the 'general' service
> > descriptions is a very good thing. Especially when you consider the
> > complexity parameters would add to xquery syntax clients would need to
> > use to make queries of the LS.
>
> XQuery will be even easier. It doesn't change anything, just the 
> syntax. For example:
>
> - //nmwg:metadata/nmwg:subject/nmwg:service/psservice:serviceName
> - 
> //nmwg:metadata/nmwg:parameters/nmwg:parameter[@name="serviceName"]
>
> OK, 4 characters more... ;-)

It doesn't come down to just characters count or syntax rearranging 
here, it comes down to making sensible statements.  XPath/XQuery are 
hard enough for non experts to learn and use, and a statement such as:

//nmwg:metadata/nmwg:parameters/nmwg:parameter[@name="serviceType" and 
text()="MA"]/../nmwg:parameter[@name="serviceName" and 
text()="internet2.edu"]

is hard to think about (and create) with the use or repeated elements 
and non descriptive element names.  Something like this is easier 
(although still hard to create) in my opinion:

//nmwg:metadata/perfsonar:subject/psservice:service/psservice:serviceType[text()="MA"]/../psservice:serviceName[text()="internet2.edu"]

Part of the appeal of having defined elements is that they carry with 
them descriptive information (psservice:serviceType says a lot more 
about what this particular element does and contains than by using 
nmwg:parameter[@name="serviceType"]). 


> > Is the motivation that you don't want to add more ggf elements?
> Yes, that's the motivation; but not only -- see the beginning of my 
> e-mail.
>
> > If so,
> > you might think about how this will effect your future DOM
> > implementation. I suspect it complicates that.
> >
> NO, it doestn't change anything. DOM is the implementation. DOM is 
> flexible, you may use both structures exactly the same. Id doesn't 
> complicate anything (the structure is simpler in fact, so it may even 
> simplify that)

I don't believe that constructing a workaround to avoid adding new 
handling elements should be included as motivation for this approach.  
When the DOM implementation is ready it won't matter how many or what 
kinds of elements are described through the schema, therefore abandoning 
the current way of doing things for simplicity now doesn't make much 
sense. 


> > Now, I do think that using parameters could be a useful way to add
> > service specific information. i.e. Extra information a service might
> > want to register about itself that does not fit in the structured 
> lookup
> > information. But, things that are useful for all services to register,
> > should be done in a well structured way in my opinion.
>
> The new structure will be well structured. Initially I thought we 
> could use mixed-type: fields we already have + parameters for new 
> service-specitic attributes, but, doesn't it complicate the structure 
> more than using just parameters? That was the idea - to keep it simple.


I don't see how this can be made well structured without explicit 
changes to the schema, perhaps I am missing where things will be checked 
and verified.


> > I already gave my opinion of the general change. But, I'm curious 
> about the specifics here as well.
> > Why not just use:
> >
> > <nmwg:parameter name="supportedEventTypes">
> >     <nmwg:eventType>eventType1</nmwg:eventType>
> >     <nmwg:eventType>eventType2</nmwg:eventType>
> >     <nmwg:eventType>eventType3</nmwg:eventType>
> >     <nmwg:eventType>eventType4</nmwg:eventType>
> >     <nmwg:eventType>eventType5</nmwg:eventType>
> > </nmwg:parameter>
> >
> > I don't really see the reason to put another parameters container 
> in. Or
> > any reason to use a list of parameters inside this either.
>
> Well, current implementation of NMWG classes doesn't support that.
> The second thing, the structure I gave was already agreed. That was my 
> understanding. It's difficult for me to send you what actually was 
> agreed and when, because as I told before, I lost all my e-mail 
> history. I was given the example of parameters in parameters from 
> Roman, so maybe he could disclaim what actually was the decision.
>
> For me your example is good as well, but I am not sure whether 
> eventType is allowed inside parameter now.

Currently 'anyElement' is allowed inside of parameter, so multiples of 
anything we have defined (or things that are not defined) can be used in 
this manner. 

-jason