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
At some points we talk about eliding data -- be it when the RFC6690 conversion of #2 generously offers that terms that are not understood may be ignored, or during profiling, or when information is too hidden to be found by an application that can't go down the whole tree (because it has a depth limit). Also when we think about whether a CoRAL document can be processed in a streaming fashion, there is a hint that it should be possible to act on incomplete information.
As long as it's OK not see parts of the original statement, there can't be any must-understand fields. (Otherwise there'd be the "whoops, I didn't see that" excuse). We should add a statement somewhere on this -- but I have no clue where. (We don't have a "CoRAL patterns" section). Could be a bit like this:
CoRAL can be used to build both open world systems ("if something is not said, it may or may not be true") and closed world systems ("if something is not said, it is not true"). In constrained environments (and the web in general), partial representations are often used for efficiency, e.g. when a device queries another for particular statements (e.g. using a yet to be defined FETCH version of CoRAL). To support such cases, it is convenient to build applications on open world assumptions.
In practice, that means that there should not be any attributes that are mandatory to process; for example, a form that can only be submitted at some times should not be expressed like this:
Instead, the presence of restrictions can be encoded in a component that is necessary for the application to use the form in the first place, and statements are added to relax the restrictions:
An application that understands "limited-feeding" term can be required to only submit this form if there is an "allow" property on the form which the application can understand and test for.
(On a personal note, at some point I'll need to write technical texts with examples that do without pop culture references, and that will be a very sad day).
The text was updated successfully, but these errors were encountered:
It might also help to add that "some tools built on CoRAL are expected to make this a requirement"; for example, anything that acts on an LRU cache of information WOULD PROBABLY ask to be used only with open-world vocabularies.
Putting this as one item on todays' brief CoRAL agenda part to flush out any WG concerns before committing that to text.
At some points we talk about eliding data -- be it when the RFC6690 conversion of #2 generously offers that terms that are not understood may be ignored, or during profiling, or when information is too hidden to be found by an application that can't go down the whole tree (because it has a depth limit). Also when we think about whether a CoRAL document can be processed in a streaming fashion, there is a hint that it should be possible to act on incomplete information.
As long as it's OK not see parts of the original statement, there can't be any must-understand fields. (Otherwise there'd be the "whoops, I didn't see that" excuse). We should add a statement somewhere on this -- but I have no clue where. (We don't have a "CoRAL patterns" section). Could be a bit like this:
(On a personal note, at some point I'll need to write technical texts with examples that do without pop culture references, and that will be a very sad day).
The text was updated successfully, but these errors were encountered: