Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFC for moving some elements to utility profile #31

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open

RFC for moving some elements to utility profile #31

Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
041ab46
RFC for moving some elements to utility profile
smizell Dec 3, 2015
28a3bd6
Updates per comments
smizell Jan 14, 2016
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
42 changes: 42 additions & 0 deletions text/0000-utilities-profile.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,42 @@
- Start Date: 2015-12-03
- RFC PR: (leave this empty)
- Refract Issue: (leave this empty)

# Summary

This proposes we move `extend`, `select`, and `option` from the base
specification to its own profile.

Note that I'm calling this a "profile" versus a "namespace." This is pending
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since that RFC is merged, please change this paragraph.

this [RFC](https://github.com/refractproject/rfcs/pull/30). If we do not go the
route proposed there, we can refer to this as a Utility Namespace.

# Motivation

The main motivation is to make the base specification as simple as possible. In
ever implementation we've created for consuming Refract, such as from the Parse
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Minor typo

In ever implementation...

In every implementation.

Result or API Description results, we have not needed to use any of these
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is false statement. We have used in in the Data Structure namespace and since API Description and Parse Result are building on it they are using these elements (albeit indirectly).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From https://github.com/refractproject/refract-spec/blob/master/namespaces/api-description-namespace.md#api-description-namespace :

This document extends Refract Data Structure Namespace to define REST Resource data structure elements.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note I mention here that we have no needed the values in "consuming" because these elements do not show up. We also have not needed them in the Fury adapter. So while we do need them in this particular namespace, my point is that:

  1. You could remove them from the base spec
  2. Build a library that conforms to the base spec
  3. Still be able to build/consume the structures we're using

The point was to move these out of the spec so that a library conforming to Refract would be smaller, yet still be able to get the job done.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

BUT I'm all for leaving in the spec as well. That's really the topic of discussion, as to whether they are needed for every possible profile/namespace. If we think so, let's close this RFC.

Note: you @zdne have mentioned we should address inheritance in the base spec, and if so, these element may become more important. So far, we have left the inheritance up to the Data Structure spec, which is really the place these elements are needed.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will have to support @zdne here. We are using extend, select and option extensively in Data Structure namespace.

elements.

In light of simplifying, this keeps the base specification concerned with
primitive, meta elements, and addressability.

# Detailed design

This proposal is to move `extend`, `select`, and `option` to its own
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If this is done the Data Structure namespace has to be updated accordingly...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I think the only thing required would be to say that the Data Structure namespace uses this other list of elements.

profile/namespace. Once there, the Data Structure namespace would then
reference that specification as a dependency.

# Drawbacks

This removes functionality from the base specification, and therefore limits it
in some way. The original argument was that these elements were important to
have for all other namespaces, but this has proven to not be true.

# Alternatives

The alternative is to of course not implement this RFC.

# Unresolved questions

None at this moment.