Clarity for API Description namespace #1
Conversation
|
@zdne I've updated the doc, FYI. |
| ## Combine Namespaces | ||
|
|
||
| We should combine the API Description namespace with the resource namespace. | ||
| Right now they are separate and it would be clearer if they were not. |
|
Done with the review. Please see my comments. Legend:
|
|
@zdne I've address some comments. If you can check those out, let me know, and maybe we can move forward. |
I am not sure if you wanted to push any changes to this doc (if so a commit is missing?) or by "address" you simply mean you have add your comments on my comments. In any case, I've replied to your comments on my comments 😆 |
|
I have reviewed and commented on with my opinions. |
|
@smizell what is the status of this ? |
|
@zdne I have unfortunately had no time to address this. |
|
@smizell OK but it is still open and we are totally doing it, right? 👯 |
|
@zdne Yes! I want to do it, and think it needs to be done. |
|
|
||
| ## Subclass Asset | ||
|
|
||
| We should subclass the Asset Element and add one called “messageShema” and another called “messageBody.” |
Remove "Elements in Attributes" from API description clarity
|
@danielgtaylor I've added a few comments throughout. @kylef Relying on you to address these comments through some PR to the Refract namespaces. Thanks for doing that (in advance)! |
Remove "Subclass Asset" from API description clarity
|
To me this PR is almost ready to go. The only really unresolved point seems to be the #1 (comment) The rest can be addressed later by introducing a non-breaking change. I would focus mainly on what we need now and make sure we won't have to break it tomorrow (e.g. any future changes we see happening will be non-breaking). Thoughts? |
|
@zdne I agree. I think we should:
I think Kyle has already done some of the first. |
Remove various items from Clarity API Description RFC
Rename transition attributes to data
…tion Clarity for API Description namespace
Rendered