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