Conversation
| + element: elementPointer (fixed) | ||
| + attributes | ||
| + path (enum) - Path of the referenced element to transclude instad of element itself | ||
| + element (default) |
There was a problem hiding this comment.
Didn't we reserve the keyword element?
There was a problem hiding this comment.
Ah, then perhaps this could be entire to represent the entire element.
There was a problem hiding this comment.
Just to note, we reserve it for object properties, but not sure about values (here it would be the value of the path property). With that said, it may be helpful to not use element as a possible value.
Second, do you want to require this value @kylef? I know you have expressed thinking about the Zen of Python, and it would remove a rule for the implementation (i.e. if path isn't set, do X, if not, do Y). It doesn't matter to me, so I'm just bringing it up if we want to start thinking about being more explicit with the serialization/deserialization.
smizell
left a comment
smizell
left a comment
There was a problem hiding this comment.
I like this change. Makes it a lot simpler. I don't feel too strongly about how to handle the path value of element—whether that should be element or entire. I think element makes the most sense, but I understand if you all think it should be reserved.
I also added a comment on requiring a value for path to make it more explicit.
Overall, 👍
|
Well, if we are writing down serialisation formats and rules, do we still need to reserve the |
|
Ok so are we good to go with this RFC @pksunkara ? |
|
Yup, didn't realise |
3 participants
Element Pointer is currently a special case and the only type that does not extend from an element which means it has special rules when it comes to serialisation and de-serialisations. These have been brought up in the discussion at #36 (comment) and while we are at it, I think it makes sense for the element pointer to become an element.