[glue-wg] GLUE WG teleconference, Tuesday, June 3, 2014

[Warren Smith]

I think the options to represent Associations are:

1) Always bidirectionally - the object on each side of the association contains the ID of the other.

2) Support bidirectionally, but recommend unidirectional in some cases - the current text.

3) Typically unidirectionally - modify the schema to remove some references along the lines of 2). Similar to your SHOULD -> MUST comment, but represented in the schema.

I/we didn't like 1), because it didn't make sense in places (e.g. a Location very rarely changes, but the entities associated with it do).

3) has some advantages, but it reduces flexibility for the end user - perhaps the directions we pick for representing associations won't be good ones for everyone.

2) was our middle ground. It allows flexibility but provides some guidance on what we think are best practices. You're right that to be robust, a tool parsing a JSON GLUE2 document of this type can't depend on what we recommend. If the association isn't represented in the direction the tool expects, it has to know to look through the objects that could be on the other side of the association.

I'd be fine with 2) or 3). I think there are advantages/disadvantages to both.


Regarding "fastest changing", yep, you're correct. I changed the text to say created/deleted instead. This is what we were thinking, I just didn't express it correctly.


The schema itself identifies mandatory attributes, so I don't think we mentioned it in the document. Examples of different Multiplicities from the spec:

"1" - ID in https://github.com/OGF-GLUE/JSON/blob/master/schema/Entity.json, where the type of the ID property is a simple type (string) and the bottom states that the ID property is required.

"0..1" - the Name property in Entity.json, where the type is a simple type (string) and that property is not required

"*" - the OtherInfo property in Entity.json, where the type is an array, the values of the array are of type string

"1-*" - the ResourceID property under Associations in https://github.com/OGF-GLUE/JSON/blob/master/schema/Manager.json, where the type is array, the values of the array are of type string, minItems is 1, and ResourceID (and Associations) are required. (I actually missed putting minItems here in the schema and I just fixed that)


JSON doesn't have namespaces as far as I've seen - it has a general philosophy of keeping things simple. So, the tool validating a JSON document needs to know what sort of document it is out-of-band. JSON schema documents have ids and can refer to other JSON schema documents by id. As you say, without namespaces, this means that when a JSON schema uses another schema, they have to be written so that they don't conflict.


Warren

________________________________________
From: stephen.burke at stfc.ac.uk [stephen.burke at stfc.ac.uk]
Sent: Thursday, June 05, 2014 5:49 AM
To: Warren Smith; navarro at mcs.anl.gov; glue-wg at ogf.org
Subject: RE: GLUE WG teleconference, Tuesday, June 3, 2014

Warren Smith [mailto:wsmith at 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.