Comments (5)
I like the overall idea here, although i have some questions/concerns :—
-
Although the description defines
available_on
as an array of class names, the actual JSON schema expects it to be an object with aclass
property (which is then an array of class names), leaving an open (unrealized) potential for other ways of determiningavailable_on
. I think we might need more clarity about whatavailable_on
actually means and whether supporting other kinds of availability other than “classes” is actually a door we want to leave open. -
I worry that the subclassing here will make it harder to do generic code: Since
General
objects will have anagent:contributor
property butGeospatial
objects will have anagent: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 aGeospatial
and aGeneral
, 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 onGeospatial
but fall back to properties defined onGeneral
when noGeospatial
property is defined. However, this is a much bigger change to the model. -
<<
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.
Related Issues (7)
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from houndstooth.