perfsonar development work

["Jeff W. Boote" <>]

Loukik Kudarimoti wrote:
> > I would prefer something that organized based on message type and data 
> > type. And, I actually like the way it is currently divided between 
> > base schema (rnc's) and examples (instance docs). So, I would prefer 
> > to keep the existing organization under 'schema'. But, I agree the 
> > examples (instance docs) organization needs work. How about something 
> > like:
> >
> > perfsonar/schema    # current rnc's (including sub-dir's)
> >     # But, documentation needs to be added. I'm somewhat ambivalent if 
> > this is done by better annotations in the rnc's, or done with 
> > documents on the side. (All things being equal, I would probably 
> > prefer annotations - I would expect that to stay in sync with the rnc 
> > better.)
>
>
> In my opinion, Annotations cannot give "the big picture" and the "best 
> practices" that an adopter of schemas or a newbie is in much need of.

Both are needed. Notice that I did put an 
'overview_of_metadata-data_structure.html' document at the top of the 
schema-profiles directory.

> > perfsonar/schema-profiles/
> >         overview_of_metadata-data_structure.html
> >         /messages/
> >             message_description.(anything but .doc ;) )
> >                 # includes how different data types are included
> >             # examples of messages
> >             SetupData.xml
> >             KeyRequest.xml
> >         /datatypes/
> >             /ping/
> >             /snmp-utilization/
> >             /owamp/
>
>
> I am a bit confused with the above structure (mainly for the examples 
> part). When you say /messages/ does it mean 
> perfsonar/schema-profiles/messages/ or perfsonar/messages/ ? I have for 
> now assumed the former. Please correct me if I am wrong. What will go 
> into /datatypes/snmp-utilization/?

Something that fills in metadata and data to help explain the specific 
parameters in the metadata that are required for utilization data. It could be 
inside a SetupData message, or a MeasurementRequest, or even a Store. The 
important part is showing the specific subjects/parameters that are needed along 
with the specific Datum for that datatype. Actually, now that you mention it - 
it would probably be better to call /datatypes/ /eventtypes/.

> We need example messages for each type of message for each type of 
> service (we use these examples for testing a service installation as well).

Sure - but like I said. The MA and MP should be sharing several message types. 
So, organizing the directory structure based on the type of service will cause 
the same message to be put in multiple places. Instead, just create a directory 
for each message type. The testing of a service can use more than one of these 
directories to include all the message types it implements.

jeff