Warren Smith [mailto:wsmith@tacc.utexas.edu] said:
For the JSON discussion, the current document is at:
https://docs.google.com/document/d/1BDemCYaJ2hkYMFvyLyJ8ZiFUwB 8tBZESo4KSFT27MaI/edit?usp=sharing
I think I've said this before, but the statement that unidirectional associations SHOULD follow certain rules, rather than MUST, seems to me to be problematic. For a client it makes life difficult because it may have to try both directions to see which one works, potentially with quite different query structures, and for a publisher the objects at either end of the relation may be created in different places, making it difficult or impossible to be sure that at least one direction is defined. What's the argument for allowing the behaviour to vary? I'm also not sure what you mean by the "fastest changing" rule - if the content of an object varies it doesn't make a difference to how easy the references are to create, the only issue is if the ID itself may change. So for example for ComputingActivities you have an object per job and there the entire object may come and go rapidly, but changing job counts in a ComputingEndpoint don't affect the long-term nature of the Endpoint as a whole. You don't explicitly mention mandatory vs optional attributes - is everything optional? How does namespacing work in JSON? You don't have any prefix for either object or attribute names, is there no risk of clashes? Even within GLUE itself I don't think we disallow attribute names to clash between object types. Stephen -- Scanned by iCritical.