Subject: [core] Some terminology questions for CoRAL

From: Jim Schaad <[email-masked]>
Date: Tue, 26 Nov 2019 18:16:29 -0800

I have been having some problems understanding one of the ways that CoRAL is
currently being described as being expressed.  I think that I have narrowed
down the issue to where I am not groking things.

The current document says that you have a context and anything which is a
URI would be resolved using that context.  The default context for anything
that is returned from the server to the client is specified as the URI that
corresponded to the request.  This makes a lot of sense.  The reverse is
also going to be true for CoRAL documents sent from the client to the
server.  In terms of the pub sub draft, an update of a topic for which the
data item is a child node would be expressed as

Max-rate 60
Topic-title  "Change to this title"
Topic-data <data> {
     Value  "90"
}    

In this case <data> is evaluated relative to the path where the document was
posted.  Next comes where I have run into my problem.  I am going to send a
request to create a topic from scratch.  In this case I am going to send a
CoRAL document to create a new topic would look like

Topic _ {
    Topic-title "This is a new topic"
}
Topic-data _ {
   Content-type 29
}

So, in my mind, both topic and topic-data have a URI as a target.  However,
in this case the value of that URI is completely unknown to the client that
is requesting that the topic be created.   My problem is that I still want
to put a URI as the target and not a literal which is what the underscore
character is.  I think this issue only arises in the cases where the target
is always going to be a URI in a response, and might be URI in the request
but not always.  In the cases where it is not a URI, it is never going to be
a literal value it is always going to be of the sense "I don't know what
goes here" or "There may be multiple answers to what goes here".  The first
case matches to the creation case.  The second case matches a query case
such as a FETCH operation.

While my personal preference here would be to use something that would not
ever be used as a literal value, as long as it gets documented in the CoRAL
document I would be able to live with any value.   The CBOR value of
"Undefined Value" (simple value 23) leaps to mind as a reasonable value to
put here depending on how the PATCH format is defined.  It may be that this
should be saved for delete.

Jim

---

From: Klaus Hartke <[email-masked]>
Date: Wed, 27 Nov 2019 08:22:34 +0100

Hi Jim,

I think when you're creating a topic, then you'll basically want to
say: "Hello server! Please create a new topic for me. The title of the
new topic should be 'This is a new topic'. There should also be a data
resource. I don't know the URI of that resource, but it should have
content-type 29."

"I don't know the URI of that resource" is literally the definition of
"null" in I-D.ietf-core-coral-01. So, when submitting a document to a
server, it could be put wherever the server is supposed to fill
something in, like the URI of the topic data resource or the blank
parts of a FETCH query.

That's the idea so far. I guess ambiguity arises when you want to be
able to both express "I want the link target to be a resource that I
don't know the URI of" and "I want you to fill in the link target".
For that, maybe using "null" and "undefined", respectively, would be a
good idea. The question is, do we need it?

The syntax for selectors and updated values in a PATCH request is an
open issue. We'll probably need to be able to say both "Please set the
link target to a resource that I don't know the URI of" and "Please
remove this link". We could distinguish between these two cases by
using "null" and "undefined" for the updated value, respectively...

Klaus