Hi Stephen, all On 2014-06-02 18:50, stephen.burke@stfc.ac.uk wrote:

[...]

Looking at Florido's last mail, I have a problem with this comment:

"1) ABSTRACT classes to be in sync with XML realisation: Objects like Entity, Resource, Share, Policy have been declared ABSTRACT to be in sync with the XML schema. This means these cannot be instantiated as is; only their specialization can (i.e. Computing- Storage- or others like Benchmark etc.) are objects that can be published."

That seems to contradict a statement in the last version of the rendering document that I've seen:

* All classes deriving from Entity will be of type "Structural".

I think you're right. I can change everything back to structural again. I think my overdoing was due to a mix of the ABSTRACT and STRUCTURAL in the previous schema.

It was a deliberate decision for LDAP that at least Resource, Share, Manager and Activity should be instantiable to allow prototyping new classes, given the difficulty in craeting and deploying a new version of the schema.

This is not really true, by declaring them abstract one forces a person to extend these classes and not change anything inside them. Even though they are abstract they can be used the same way we do with ComputingShare etc.

Previous versions of the document had some explicit text to explain that, and I don't think we ever discussed a change to that.

You're right. To avoid further discussion which I think is of no use now I will just revert everything back to STRUCTURAL.

For those classes there is no fundamental reason that they should not be instantiable, it's just that the base classes have no attributes and hence aren't useful in themselves, but you can still usefully add Extensions to prototype new attributes. By contrast there isn't likely to be any use in having Policy and Domain be instantiable, but equally it would do no particular harm.

I agree. But let's stick to the document as you suggested. Sorry about that. I'll try to fix it before the meeting starts. Cheers, Florido -- ================================================== Florido Paganelli ARC Middleware Developer - NorduGrid Collaboration System Administrator Lund University Department of Physics Division of Particle Physics BOX118 221 00 Lund Office Location: Fysikum, Hus B, Rum B313 Office Tel: 046-2220272 Email: florido.paganelli@REMOVE_THIShep.lu.se Homepage: http://www.hep.lu.se/staff/paganelli ==================================================

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@stfc.ac.uk [stephen.burke@stfc.ac.uk] Sent: Thursday, June 05, 2014 5:49 AM To: Warren Smith; navarro@mcs.anl.gov; glue-wg@ogf.org Subject: RE: GLUE WG teleconference, Tuesday, June 3, 2014 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.

Navarro, John-Paul F. [mailto:navarro@mcs.anl.gov] said:

Action 4: JP/Shiraz will send out for final 1 week comment request to glue-wg

In the last week of June and the first week of July I may have difficulty meeting a one-week deadline.

Agreed 1: Enumerations are case sensitive as defined by the schema entities that they describe Agreed 2: Prohibit the use of multiple enumerations that only vary in case

And make it clear that lowercase is RECOMMENDED - exceptions should be justified and rare, other than where we already have mixed case values in use (e.g. MyProxy). Stephen -- Scanned by iCritical.