You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It might be nice to have a "mini-spec" describing a simple referencing extension to core KDL that will allow for internal references/links between nodes.
I think this needs to percolate for a bit, though. I really REALLY don't want this to a general expectation of implementations, but I can see some utility in defining it such that DSL authors who want this kind of linking (for example, I'm doing it a lot in the KDL Schema spec) will have "ready-made" syntax and semantics, and possibly even supporting libraries (even if they happen to be bundled with parsers), that will provide this functionality in a well-known, understood way that has already been carefully thought through by a good number of people.
This is pretty important because we start getting into some hairy security implications with this design, some of which we may just not be able to address.
I guess we can literally say "Implementations MUST NOT interpret references in KDL documents except as either a second, explicit path over a parsed document, or as an opt-in option that makes the choice to resolve them clear, explicit, and dependent on the particular format/schema being handled."
I think this way works, because then we wouldn't have to worry about "reserving" anything: if you opt into referencing, you have understood that the format you're developing is going to have certain restricted properties (namely $id, $ref, and $ref-kpath).
The text was updated successfully, but these errors were encountered:
It might be nice to have a "mini-spec" describing a simple referencing extension to core KDL that will allow for internal references/links between nodes.
For example:
Would be equivalent to:
I think this needs to percolate for a bit, though. I really REALLY don't want this to a general expectation of implementations, but I can see some utility in defining it such that DSL authors who want this kind of linking (for example, I'm doing it a lot in the KDL Schema spec) will have "ready-made" syntax and semantics, and possibly even supporting libraries (even if they happen to be bundled with parsers), that will provide this functionality in a well-known, understood way that has already been carefully thought through by a good number of people.
This is pretty important because we start getting into some hairy security implications with this design, some of which we may just not be able to address.
I guess we can literally say "Implementations MUST NOT interpret references in KDL documents except as either a second, explicit path over a parsed document, or as an opt-in option that makes the choice to resolve them clear, explicit, and dependent on the particular format/schema being handled."
I think this way works, because then we wouldn't have to worry about "reserving" anything: if you opt into referencing, you have understood that the format you're developing is going to have certain restricted properties (namely
$id
,$ref
, and$ref-kpath
).The text was updated successfully, but these errors were encountered: