constraint 2.0 about mdjson-schemas HOT 15 CLOSED

Aren't constraint->reference->responsibleParty and constraint->responsibleParty redundant? Do we need both?

from mdjson-schemas.

Are they the same? No. Do we need both? Don't know. constraint > reference >responsibleParty is the responsible party within citation. constraint > responsibleParty is the responsible party for the constraint. Personally I would not fill in the responsible party for the citation.

from mdjson-schemas.

What's the difference between "useLimitation" and "legalConstraint > useConstraint". Are these equivalent?

Given the updated structure, I don't see why we can't put the properties from legalConstraint and securityConstraint into the root constraint object. The property names are all distinct, and since type is required I don't see a need to maintain these separate objects.

from mdjson-schemas.

All the elements of 'constraint' and also valid in 'legalConstraint' and 'securityConstraint'. I repeated the elements in mdJson so that populating 'constraint' elements would not be a prerequisite to declaring a legal or security constraint. This also works nicely with using 'type=' to set the constraint type. This way all the constraint objects can be elements of the same 'constraint' array and mixed in whatever order. All constraints look the same, just that legal and security constraints have a few additional elements. These types are normalized in the internal object.

'useLimitation' is a limitation for using the data that is neither legally binding or a security restriction.

from mdjson-schemas.

I still don't see why we need the extra objects if we're declaring a type. Seems like we can just have one constraint object with all the properties. Choosing a type would determine which ones are required.

from mdjson-schemas.

Declaring the type does not set requirements since none of the legalConstraints are required and only one secruityConstraint is required. Type only sets which elements are available. Typically I don't like to combine rule sets. If the constraint type='use' legal and security elements are not allowed, if type='legal' one legal element is required but no security elements, etc. Putting all the elements in one objects puts more work on the application. But do what you want, I'll adjust.

from mdjson-schemas.

If you change to a single object do set some rules for me. Are we still declaring type? If the user set attributes outside of the declared type do we discard them? If the use specifies both legal and security elements do we generate multiple constraints? etc.

from mdjson-schemas.

Yeah, that only works if we're declaring "type". If the user sets attributes outside of the declared type I wouldn't just ignore them. In the case of the mdTranslator I'd read them in and handle any discards in the writer. I can set required properties in the schema based on the type.

from mdjson-schemas.

It will make no sense if the user set attributes outside the declared type so they should be discarded. Actually, the common elements define the constraint and the extra legal or security set aspects of specific types of constraints. Legal and security constraints are two different constraints and would correspondingly have different use type elements.

Remember too constraints are complex. Last time I modified constraints it impacted 30 modules.

from mdjson-schemas.

Here's an example of dropping the explicit "type" declaration. Instead of reading the type from the "type" property(like this), we can just grab it from the constraint property name:

type = %w{ legal security useLimitation}.find { |word| hConstraint.has_key?(word)}

If no "legal" or "security" property exists, then type will be useLimitation (the schema requires at least one of those properties). Note, that the type can still be set on the internal object, so no change to the writer. This example is probably the most complicated since it's mixing in other properties and we're not dealing with separate objects. Thoughts?

from mdjson-schemas.

Not sure how this would work in all Ruby compilers. Legal and security constraints also have useLimitations. The find block would search for all the types in the list until one is found, but order is not required in JSON, so the mdJson file could place these blocks in any order.

from mdjson-schemas.

The find would search in the order of %w{ legal security useLimitation}. So it would basically default to useLimitation.

from mdjson-schemas.

"useLimitation" is not required, so may not be present in which nil would be returned (no problem) if "security" or "legal" we also not present. However, "legal", "security", and "useLimitation" could all be present in any mdJson "constraint" object in which case the presence of an element does not guarantee the type of constraint.

from mdjson-schemas.

Yeah, I think that's a problem. We probably shouldn't allow both "security" and "legal" in the same object instance if we're relying on "type". I think it's not very clear that if you set type="legal", the "security" object is not going to be translated.

from mdjson-schemas.

We can't get completely away from it. "useLimitation" is present in all types. It's impossible to control what elements are present in JSON not knowing the creation source. All we could do is reject the file. I don't think we need to go to that extreme. This is a tricky one and the only one quite like it. I have reorganized it 3 times now. The last time took 1.5 days and effected 37 modules.

from mdjson-schemas.