Moves Compact Refract to separate file#53
Conversation
|
See #55 as accompanying issue. |
README.md
Outdated
There was a problem hiding this comment.
Both this PR and https://github.com/refractproject/refract-spec/pull/52/files#diff-04c6e90faac2675aa89e2176d2eec7d8R14 changes version to 0.7.0.
I think these PRs shouldn't change the version number. Instead once both have been merged, there should be a separate release PR (once we deem ready for release, perhaps other upcoming changes can make it into this release too).
There was a problem hiding this comment.
Agreed. I'll change.
formats/compact-refract.md
Outdated
There was a problem hiding this comment.
Is this required here? We don't define Element Pointer or string here either since it's in the base spec, I assume.
There was a problem hiding this comment.
Unfortunately, I think so unless we use the base spec's serialization format.
["foo",
{
"links":[
{
"element": "link",
"attributes": {
"relateion": "bar",
"href": "/something/1"
}
}
]
},
{},
"bar"
]There was a problem hiding this comment.
Why is this in two lines?
There was a problem hiding this comment.
My editor splits it automatically 80 characters. I can change back.
On Sun, Jan 17, 2016 at 8:32 AM Z notifications@github.com wrote:
In formats/compact-refract.md
#53 (comment)
:@@ -0,0 +1,80 @@
+# Compact Refract
+
+Compact Refract is a serialization format Refract for the purpose of removing a
+lot of the object keys that are repeated throughout the full serialization of
+Refract, as seen in the Refract specification. It also allows for expressing
+structures in a tuple, which resembles other formats like XML or Lisp.
+
+## Dependencies
+
+- Refract Base
+Specification80 cols per a line I guess
—
Reply to this email directly or view it on GitHub
https://github.com/refractproject/refract-spec/pull/53/files#r49947003.
Moves Compact Refract to separate file
|
@smizell Merged. Please update the relevant RFC/issues. |
This moves Compact Refract out of the base spec to its own spec. Note that this does in a sense break the spec, but it also simplifies that clients do not need to support it to support the base spec. This is the reason for bumping the version number.
Another thing to note is that I have not defined all primitive elements here. For one, I’m trying to work through this quickly and I want to consider this to be a serialization format and not defining a specific structure like the base spec does.