[nm-wg] Boston Discussion Points

[Jason Zurawski]

All;

Here is a loose list of topics that should be addressed in Boston:

 - Schema Versioning
        - I will be making a proposal for PerfSONAR on this topic very 
soon, but the NMWG community should have a crack at this as well.  We 
are leaning to a namespace structure such as this:

          http://ggf.org/ns/0.0.1/nmwg/

          This idea allows for mix/matching of versioned elements (if 
this is what you require).  Of course arguments can be made to replace 
the periods with slashes, although this complicates the directory 
structure.  Another issue for discussion is what to do in the default 
case (when a version is not specified).
 
 - Response Codes, Exceptions, etc.
       - There is a simple proposal going around on the sonar mailing 
list suggesting that codes (perhaps textual responses) can be returned 
as datum elements in some sort of 'response' namespace.  To simplify 
data transmission codes only can be enforced, and lookup calls can be 
implemented by the client software to expand error messages (http 
like).  Regardless, this allows for a data element to be returned with 
various (or singular) datum representations of server state.

 - Characteristic as optional element in metadata
         - We think bringing this back in will not harm anything (still 
rely on the namespace when applicable), and it can also be used for 
response codes, versioning, etc. 

 - Bag of parameters for message and store
       - A 'bag' of parameters is as such:

<nmwg:parameters id="id1">
  <nmwg:parameter name="units" value="Mb/s" />
  <select:parameter name="time" operation="gte" value="1127250485" />
  <select:parameter name="time" operation="lt" value="1127255485" />
</nmwg:parameters>

       The generic 'name/value' (optional 'operation' in some 
namespaces) attributes allow arbitrary specification of requirements.  
We are using these in sonar for SQL like statements to limit data 
representation; the concept can be extended to the 'common' element idea 
(such as for units or time), or just as a way to specify arbitrary ideas 
(message keepalive, message authentication, etc.).  The parameters block 
can be instantiated at any level (we are thinking) such as inside of a 
metadata, data, or message block. 

    - Munging GridFTP logs into a schema
       - If anyone has a pointer to some real logs I can rough something 
out.

     - Community involvement in schema design
       - We have wanted this all along, but the question remains how we 
can ensure new schemas conform to our general format.  Some sort of 
'translation' system can be devised using known schemas and perhaps 
xslt?  Still a lot to talk about on this one.
  
-jason