Week of Sep 1#405
Conversation
ce65f71 to
1008861
Compare
jskeet
left a comment
There was a problem hiding this comment.
I've only skimmed, and there are a few comments, but broadly speaking this looks fine to me.
| Registry, while Groups, as the name implies, is a mechanism by which related | ||
| Resources are arranged together under a single collection. | ||
| Resources typically represent the main data of interest in the Registry, while | ||
| Groups, as the name implies, is a mechanism by which related Resources are |
There was a problem hiding this comment.
While I can see that it's a singular feature being described, the "Groups is a mechanism" jars a bit.
Would "while Groups, as the name implies, allow related Resources to be arranged together under a single collection" work?
|
|
||
| #### Group | ||
|
|
||
| Groups, as the name implies, is a mechanism by which related Resources are |
| ``` | ||
|
|
||
| ## Notations and Terminology | ||
| ### Registry Views |
There was a problem hiding this comment.
Wow, GitHub is choosing a really odd diff here...
There was a problem hiding this comment.
yep, I guess that's what happens when you move too many large chunks of text around.
Wait for next week's PR... it'll be a doozy too
| In this view clients are retrieving all (or part) of the Registry hierarchy | ||
| as a single document. In this case nested (or child) entities are "inlined" | ||
| into the retrieved document such that the need for secondary interactions | ||
| with the server is reduced. |
There was a problem hiding this comment.
| In this view clients are retrieving all (or part) of the Registry hierarchy | |
| as a single document. In this case nested (or child) entities are "inlined" | |
| into the retrieved document such that the need for secondary interactions | |
| with the server is reduced. | |
| In this view, clients are retrieving all (or part) of the Registry hierarchy | |
| as a single document. In this case, nested (or child) entities are "inlined" | |
| into the retrieved document such that the need for secondary interactions | |
| with the server is reduced. |
| Resources, while possible, might be cumbersome, so moving it up to the Group | ||
| could be a more manageable, and user-friendly, implementation choice. | ||
| This is often used for cases where the documents are to be stored in some | ||
| document storage system (e.g. github), or as input into local tooling that |
There was a problem hiding this comment.
| document storage system (e.g. github), or as input into local tooling that | |
| document storage system (e.g. GitHub), or as input into local tooling that |
| Additionally, Resources (unlike Groups) MAY be versioned. | ||
|
|
||
| #### Version | ||
| In this view it is assumed that the client is interested in an interactive |
There was a problem hiding this comment.
| In this view it is assumed that the client is interested in an interactive | |
| In this view, it is assumed that the client is interested in an interactive |
| - Multiple Document View | ||
|
|
||
| ## Registry Design | ||
| This is a variant of the "api view". In situations where the data within the |
There was a problem hiding this comment.
| This is a variant of the "api view". In situations where the data within the | |
| This is a variant of the "API view". In situations where the data within the |
|
|
||
| ## Registry Design | ||
| This is a variant of the "api view". In situations where the data within the | ||
| xRegistry is to be stored as independent files either on disk or in some |
There was a problem hiding this comment.
should this be Registry?
There was a problem hiding this comment.
done but it's a question I've been meaning to ask.... when do we use xRegistry vs Registry ?
There was a problem hiding this comment.
I don't know, I would prefer xRegistry, but above that, I prefer consistency (I'm a good student 😉)
| This entity is meant to serve a few key purposes: | ||
| Documents generated in this view are often stored locally such that they can | ||
| be managed independently for use in tooling or stored in some source-code | ||
| control system (e.g. github) to minimize the number of conflicting edits |
There was a problem hiding this comment.
| control system (e.g. github) to minimize the number of conflicting edits | |
| control system (e.g. GitHub) to minimize the number of conflicting edits |
| ### Registry Views | ||
|
|
||
| This specification defines the following terms: | ||
| This specification is designed such that clients can choose how they want the |
There was a problem hiding this comment.
Could it be useful to mention the hasdoc aspect in this section as well, because it's mentioned through the ?doc, but it's not entirely clear at this point what that means.
There was a problem hiding this comment.
Actually, it is mentioned just above, so maybe it's fine.
There was a problem hiding this comment.
Let's see how the major "core vs http" split looks and see if we need to do it after that.
- New text and moving more stuff around - add definition of "capabilities" attribute to Registry entity's list of attributes - info about the different 'views' Signed-off-by: Doug Davis <duglin@gmail.com>
|
Approved on the 9/11 call |
Uh oh!
There was an error while loading. Please reload this page.