Use inheritance instead of key matching? about houndstooth HOT 5 OPEN

I like the overall idea here, although i have some questions/concerns :—

1. Although the description defines available_on as an array of class names, the actual JSON schema expects it to be an object with a class property (which is then an array of class names), leaving an open (unrealized) potential for other ways of determining available_on. I think we might need more clarity about what available_on actually means and whether supporting other kinds of availability other than “classes” is actually a door we want to leave open.

2. I worry that the subclassing here will make it harder to do generic code: Since General objects will have an agent:contributor property but Geospatial objects will have an agent:contibutor:geospatial property, it becomes more complicated writing code which handles both. Plus, it requires a stronger linkage between classes in code and in the metadata schema—it would be a problem if a class considered itself to be both a Geospatial and a General, because it would then have the property twice.

   In an ideal world, I’d probably rather things look like this :—

   properties:
   
   - &agent:contributor
     name: agent:contributor # the name for computers
     label: Contributor # the name for humans
     available_on:
       class: # ???
       - General
     usage_guidelines: Some general guidelines
   
   - <<: *agent:contributor
     # has the same name as above
     # it is up to implementations to resolve this conflict
     available_on:
       class: # ???
       - Geospatial
     usage_guidelines: Some specific guidelines

   Then an implementation could easily prioritize the agent:contributor defined on Geospatial but fall back to properties defined on General when no Geospatial property is defined. However, this is a much bigger change to the model.

3. << is a YAML 1.1 feature which is supported in Ruby, but it was dropped from YAML 1.2. I don’t think this is an argument against using it, but we should maybe be conscious that YAML 1.2‐based implementations might need to do a little more work.

from houndstooth.

Although the description defines available_on as an array of class names, the actual JSON schema expects it to be an object with a class property (which is then an array of class names), leaving an open (unrealized) potential for other ways of determining available_on. I think we might need more clarity about what available_on actually means and whether supporting other kinds of availability other than “classes” is actually a door we want to leave open.

i think we should seriously consider foreclosing this. right now, it's possible to describe M3's basic function in terms of two abstractions:

• Class
• Property (or maybe property specifications)
  we can say M3 defines schemas by listing a set of Classes and a set of Property specs, and mapping the latter onto the former. if this is a good description (is it?) introducing another way of applying properties complicates things for us.

if this sounds reasonable, i'd like to open a ticket to somehow formalize this way of looking at what M3 does.

from houndstooth.

I worry that the subclassing here will make it harder to do generic code

i think you're right about this, and the kind of solution you're pointing to is the kind i would have in mind. i think the assumption that the YAML key defines the ruby method name, or the "property name" is problematic in general. if M3 is interested in defining property names, i think it's helpful to do so explicitly with a name key (and ideally allow implementations to make their own judgements about whether those are appropriate internal property keys).

from houndstooth.

<< is a YAML 1.1 feature which is supported in Ruby, but it was dropped from YAML 1.2.

if it's okay to say "M3 supports YAML 1.1" (i hope this is okay), i think we should do that. YAML 1.2 support can be a question for another day.

from houndstooth.

i think we should seriously consider foreclosing this.

This would be my preference too.

if M3 is interested in defining property names, i think it's helpful to do so explicitly with a name key

The main motivation here being a general sense of “an implementation should support at most one definition with this name on any given object”, and nothing stricter than that. I think that is the requirement we are looking for with this usecase.

if it's okay to say "M3 supports YAML 1.1" (i hope this is okay), i think we should do that.

I think this is okay, and YAML 1.2 processors which don’t support << magic would (I think) just interpret it as a key named <<. I think that’s a fine fallback; it would just mean those implementations would have to check for that key and carry forward any properties available there.

from houndstooth.