confused with instances links vs schema links: help needed

[Philippe Marsteau]

Hi,

I am pretty new to the json schema topics, and try to get my head around how to define link relationships within json instances.

What I understood so far, is schemas allow to define and document the link relationships, including the query parameters (properties of link description).

Where I struggle is how to remain HATEOS with consumers, which is my understanding only the producer should generate links, the client should only consume them (so if the server decides to change the link structure, it won't break client). Concept of URI opacity etc.

To achieve this, it is further understood that the json instances should list the links that the server computed. If one json instance links to another (based on the definition from the schema) the producer should still list the links computed (the server will follow the schema to construct the links).

So HOW does a json instance instruct link relationships to another? What I came so far was to have the schema lists (1) the properties, including an array of links, and (2) the links section, defining the possible link relationships (that the json instance will eventually return as part of its properties).

Below an example:

json-schema sample:

{

    "$schema": "http://json-schema.org/draft-03/hyper-schema#",

    "id": "myownschema.json",

    "type": "object",

    "properties":

    {

        "propA":

        {

            "type": "string",

            "required": true            

        },

        "links":

        {

            "type": "array",

            "items":

            {

                "$ref": "http://json-schema.org/draft-03/links#"

            }

        }

    },

    "links": [

    {

        "href": "/api",

        "rel": "parent",        

    },

    {

        "href": "/api/{propA}",

        "rel": "canonical",        

    },

    {

        "href": "https://link.to/myownschema.json",

        "rel": "describedby"

    }]

}

json instance sample:

{

   "propA": "somevalue",

   "links": [

     {"rel": "canonical", "href": "/api/somevalue"},

     {"rel": "parent", "href": "/api"},

     {"rel": "describedby", "href": "https://link.to/myownschema.json"}

   ]

}

Is that the wrong way of doing it? I know most people do not use links in the properties, assuming they don't need to, being described by the schema itself. But I omit these, how could a consumer follow the link relation without computing the link on the client side? If only the server can compute the link "href", then it has to be returned somehow in the json instance, shouldn't it? (could be HTTP Link Header or part of payload, but somehow it must be computed values, the client just "blindly" follow).

Thoughts?

Another question: does it make sense the json instance itself contain a "$schema" property (as a way to indicate the payload should conform to a specific profile/schema)?

Thank you for the help!!

PS: I know it is draft3 schema, but the question is still there in draft4.

[Geraint (David)]

The links that are defined in the schema apply to the instance, not the schema.  The flexibility of them comes from the fact that the URI for the link can be extracted from the instance data.

If you want the instance to include the complete calculated URIs for the applicable links, then you might use something like the following:

Schema:

{

    "$schema": "http://json-schema.org/draft-04/hyper-schema#",

    "id": "myownschema.json",

    "type": "object",

    "properties": {

        ...

    },

    "links": [

        {

            "href": "{+parent}",

            "rel": "parent"

        },

        {

            "href": "{+canonical}",

            "rel": "canonical"

        },

        ...

    ]

}

Data:

{

    "canonical": "/api/somevalue",

    "parent": "/api",

    ...

}

With that setup, the URIs for the links are included as part of the data.  If some links are not always present, then define them in the schema, but then don't include them in the data.

(For version 3, the schema is basically the same, but without the "+"s in the URI templates.)

On Thursday, January 31, 2013 1:50:44 PM UTC, Philippe Marsteau wrote:

Hi,

I am pretty new to the json schema topics, and try to get my head around how to define link relationships within json instances.

What I understood so far, is schemas allow to define and document the link relationships, including the query parameters (properties of link description).

Where I struggle is how to remain HATEOS with consumers, which is my understanding only the producer should generate links, the client should only consume them (so if the server decides to change the link structure, it won't break client). Concept of URI opacity etc.

The above example gives you complete URI opacity - the URIs can shuffle around and nothing will change in the client at all.

But when you say "the producer should generate links, the client should only consume them" - which side of that do JSON Hyper-Schemas fit in?  In general, the producer of the data is also the producer of the schemas, so the link definitions in the schema can still be considered as "coming from the server".

The power of hyper-schemas is that the client can take *all* of its cues from the server.  Don't stop at URI opacity - if the producer wants to change the name of the variable that the link URI is stored in, they just change the link definition in the schema - a flexibly-coded client won't even blink.

[Geraint (David)]

On Thursday, January 31, 2013 1:50:44 PM UTC, Philippe Marsteau wrote:

Sure - but $schema is not a reserved property - on its own, it doesn't mean anything.

However, you can describe that behaviour using JSON Hyper-Schema - you simply define a "describedby" link that takes its URI from the "$schema" property, e.g.:

{

    "$schema": "http://json-schema.org/draft-04/hyper-schema#",
    "links": [
        {
            "rel": "describedby",
            "href": "{+($schema)}"
        }
    ]

}

That is a declaration that if an instance described by that schema includes the "$schema" property, then it is also described by the schema at that URI.

(the equivalent "href" value for a v3 schema would be simply "{$schema}")

[Philippe Marsteau]

Thanks David for the follow up. It is still not clear to me

1) Do you agree with my understanding, that for remaining HATEOS (hypermedia driven) server serving a resource should include links in the data representation of that resource (or as Link Header if you want to keep that distinct from the data)? I believe you agree since you wrote "the flexibility of [links] comes from the fact that the URI for the link can be extracted from the instance data."

2) If you agree with 1), and assuming we do prefer making this part of data instead of Link headers, then shouldn't my "properties" section of my schema - using hyper schema, as per previous example - include an array of links? 

What I would like to achieve is to describe the complete data representation of a resource. Including data and links. Current tool that generates POJOs from json-schema (jsonschema2pojo), or POJOs to json-schemas (Jackson/Jersey) only consider the data section. As part of the implementation, I want the service to serialize data and serialize links.

That is why I added a "links" array in my data representation. Now at least json-schema to POJO generation would generate the proper bean (representing the complete instance structures, including both data properties and link properties). If instead of an array of links called "links", I wanted to represent each link as a simple property (as you proposed for "canonical" and "parent") of format URI, then I should express that as part of the properties section of my json-schema, by expressing each property of type "string", format "uri", shouldn't I?

Sorry for not getting it straight. This is extremely helpful if you could clarify.

[Philippe Marsteau]

But when you say "the producer should generate links, the client should only consume them" - which side of that do JSON Hyper-Schemas fit in?  In general, the producer of the data is also the producer of the schemas, so the link definitions in the schema can still be considered as "coming from the server".

The power of hyper-schemas is that the client can take *all* of its cues from the server.  Don't stop at URI opacity - if the producer wants to change the name of the variable that the link URI is stored in, they just change the link definition in the schema - a flexibly-coded client won't even blink.

Just realized that other portion of the reply. Are you indicating that a client could still generate the links itself, as long as it construct these by dynamically reading the json-schema? That does not always work, since some link value could be completely generated from the server, at runtime, so the client could not infer that info by simply reading the schema (for example, the "{current}" would need to be a property in the data representation of the resource. What if it is not. E.g. if I want the URL to be randomized from one endpoint to another, to handle downtime scenario, say). The URI cannot be determined by simply reading the json schema. It URI is opaque so only server knows how to build it. At least, that was my understanding.

Phil

[Geraint (David)]

Yes - that is how it works.  If you have a URI that is completely unpredictable by the client, then that URI must be included as part of the data returned by the server.

The way JSON Schema works is that the nature of the link is described ahead of time (link relation, target media type, form parameters).  But the URI can be stored in the data (completely or as part of a template), and as such can be generated at runtime by the server and simply "dropped into place" by the client when it's inspecting the data for links.

Does that make sense?

Phil

 

[Geraint (David)]

On Thursday, January 31, 2013 5:08:49 PM UTC, Philippe Marsteau wrote:

Thanks David for the follow up. It is still not clear to me

1) Do you agree with my understanding, that for remaining HATEOS (hypermedia driven) server serving a resource should include links in the data representation of that resource (or as Link Header if you want to keep that distinct from the data)? I believe you agree since you wrote "the flexibility of [links] comes from the fact that the URI for the link can be extracted from the instance data."

2) If you agree with 1), and assuming we do prefer making this part of data instead of Link headers, then shouldn't my "properties" section of my schema - using hyper schema, as per previous example - include an array of links? 

If the links are themselves completely unpredictable (not just the URI, but unpredictable link relation, target media type, and title) - then yes.  A property in the data called "links", holding an array of Link Description Objects, is the best thing to do.  At that point, you no longer need to define the links in the schema - you just describe the "links" property exactly as you did in your first example, and that's all you need to do.
 

[Geraint Luff]

On 1 February 2013 15:03, Geraint (David) <gerai...@gmail.com> wrote:

On Thursday, January 31, 2013 5:08:49 PM UTC, Philippe Marsteau wrote:

Thanks David for the follow up. It is still not clear to me

1) Do you agree with my understanding, that for remaining HATEOS (hypermedia driven) server serving a resource should include links in the data representation of that resource (or as Link Header if you want to keep that distinct from the data)? I believe you agree since you wrote "the flexibility of [links] comes from the fact that the URI for the link can be extracted from the instance data."

2) If you agree with 1), and assuming we do prefer making this part of data instead of Link headers, then shouldn't my "properties" section of my schema - using hyper schema, as per previous example - include an array of links? 

If the links are themselves completely unpredictable (not just the URI, but unpredictable link relation, target media type, and title) - then yes.  A property in the data called "links", holding an array of Link Description Objects, is the best thing to do.  At that point, you no longer need to define the links in the schema - you just describe the "links" property exactly as you did in your first example, and that's all you need to do.

 
Just to clarify (because people have been confused by this before) - the property in the data doesn't have to be called "links".  It can be anything, as long as it holds a list of LDOs.  :)
 

--
You received this message because you are subscribed to the Google Groups "JSON Schema" group.
To unsubscribe from this group and stop receiving emails from it, send an email to json-schema...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Philippe Marsteau]

If the intent of hyperschemas to let consumers build URIs themselves (using URI templates) then I believe we are fundamentally breaking the hypermedia constraint of REST. Even if a consumer is downloading the schema on each call (to get aware of URI structure changes), it would still need out of band information (coupling) as of the core part of the href (excluding the templating). That core part could change (e.g. depending on call origin, I may generate a different root href part to target the "closest" location to caller). Having that core part known to client is creating coupling unless you convey the information on each call (as part of the json instance). I agree that if I did not had that requirement of changing core part of the URI (say it would be root URI all times), I could have consumer building the other part of the "href" (using URI templating).

Now considering my use case, I do see value of hyperschema - as long as the only part consumers build is the query string part (for GET) or the forms properties (PUT/POST) a user should know to send data (using known properties, known encoding, and known link relations provided by the schema). 

What's wrong with not letting consumers build the "href" at all, and letting it be truly opaque to consumer? What's wrong with having server being the only one to know which links are indeed available or not? Because your schema documents _all_ links, it does not tell under which conditions these are available or not. As an example, a pagination "next" or "prev" link should not be always available depending which page is retrieved from the collection.

The consumer _having knowledge of the schema_ would know:

1. The relation ID and media types to lookup in the json instance (now they get the server-generated "href" value). If link is not present, consumers knows it cannot follow the link. 
   
2. The link properties (GET or POST) needed to send data to the API producer (either as query string for GET or as form for PUT/POST).
   
3. The encoding how to encode the property values of the link
4. The method to call on the provided "href" value

This way, consumer would not need the URI template knowledge at all. Only the server would. And still there would be true value of describing these links in the schema, since this one provides the details of which link relation to lookup and which properties each of these links support (not to mention the documentation aspect of it).

Maybe I am offtrack. I found pretty neat to get at glance, retrieving a json instance, which are the links I can actually follow at that given point of time. The rationale for listing some links and not others belongs to the application state and logic, and may be different on each calls. If I already need the server to send me the links, what's wrong with letting server sending the "href" value as well?

  

Thoughts?

[Geraint Luff]

On 3 February 2013 15:37, Philippe Marsteau <mars...@gmail.com> wrote:

If the intent of hyperschemas to let consumers build URIs themselves (using URI templates) then I believe we are fundamentally breaking the hypermedia constraint of REST. Even if a consumer is downloading the schema on each call (to get aware of URI structure changes), it would still need out of band information (coupling) as of the core part of the href (excluding the templating). That core part could change (e.g. depending on call origin, I may generate a different root href part to target the "closest" location to caller). Having that core part known to client is creating coupling unless you convey the information on each call (as part of the json instance). I agree that if I did not had that requirement of changing core part of the URI (say it would be root URI all times), I could have consumer building the other part of the "href" (using URI templating).

There's nothing stopping you designing your API such that the full URI for each link (not just part of it) is transmitted as part of the data.  I think that is good style.

In the example from my first reply I tried to sketch out such a scenario, and how it would be expressed using hyper-schemas.  The full URI for the "canonical" and "parent" links were supplied as part of the data.  The URI template was simply "{+parent}" - which means: take the URI from parent, as-is, without any escaping or anything else.

 

Now considering my use case, I do see value of hyperschema - as long as the only part consumers build is the query string part (for GET) or the forms properties (PUT/POST) a user should know to send data (using known properties, known encoding, and known link relations provided by the schema). 

What's wrong with not letting consumers build the "href" at all, and letting it be truly opaque to consumer? What's wrong with having server being the only one to know which links are indeed available or not? Because your schema documents _all_ links, it does not tell under which conditions these are available or not. As an example, a pagination "next" or "prev" link should not be always available depending which page is retrieved from the collection.

You still have to match up the link definitions (defining query part / form properties) with the name of the property in which the URI is stored.  For example, imagine the following (pseudo-)schema:

{

    "links": [

        {

            "rel": "search",

            "schema": {...}

        }

    ]

}

and the following data:

{

    "searchUri": "/api/search"

}

With that example, the URI is included as part of the data - but the link definition in the schema doesn't give you enough information to match up the "search" link with the "searchUri" property.

All we need to add is "href": "{+searchUri}"  - it's pretty much the simplest URI Template on Earth, and it gives the client enough information to use the "search" link without telling/assuming anything about the structure of the URI itself.

The consumer _having knowledge of the schema_ would know:

1. The relation ID and media types to lookup in the json instance (now they get the server-generated "href" value). If link is not present, consumers knows it cannot follow the link. 
   
2. The link properties (GET or POST) needed to send data to the API producer (either as query string for GET or as form for PUT/POST).
   
3. The encoding how to encode the property values of the link
4. The method to call on the provided "href" value

This way, consumer would not need the URI template knowledge at all. Only the server would. And still there would be true value of describing these links in the schema, since this one provides the details of which link relation to lookup and which properties each of these links support (not to mention the documentation aspect of it).

OK - so is what you're proposing basically not to use URI Templates?  Instead, you just nominate a property name in the data that contains the full URI?

 

--

[Philippe Marsteau]

This is not what I meant.

For the following (pseudo)schema:

{

    "properties": {

        [...]

    }

    "links": [

        {

            "rel": "search",

            "method":"POST",

            "schema": {...},

            "encType":"application/json",

            "targetSchema": {...}

        }

    ]

}

I meant receiving the following data:

{

    [...]

    "links": [ {"rel"="search", "href"="/api/search"} ]

}

Now by looking up "search" LDO in schema, I would have all further details about how to interact with that related resource (doing POST, what properties to put and how to encode, etc.).

If the "search" relation was not available at that time, then you would receive 

{

    [...]

    "links": []

}

Assuming a link does not apply if one of the property the URI template refers to does not apply might be acceptable. But what if the property does exist, but the link is not permitted, based on the application state?

See below (pseudo) schema:

{

    "properties":

     {

             "id":  { "type": "integer" }

             [...]

     }       

    "links": [

        {

            "rel": "self",

            "href: "{id}

        },

        {

            "rel": "delete",

            "href: "{id}"

            "method":"DELETE",

        }        

    ]

}

and following data

{

   "id": 123

}

What are the available link relation with that information? self? delete? both? It depends on the application logic.

Now compare with

{

   "id": 123

   "links": [ {"rel": "self", "href": "/123"}, {"rel": "delete", "href": "/123"} ]

}

tells me that both "self" and "delete" links are available.

{

   "id": 123

   "links": [ {"rel": "self", "href": "/123"}]

}

tells me that only "self" link is available.

That is what I meant. As you can see, I do leverage URI template, but simply putting the property (e.g. "id") is not sufficient information to infer which available relations are available.

Now, obviously, I could modify my schema

{

    "properties":

     {

             "id":  { "type": "integer" },

             "deleteId":  { "type": "integer" },

             [...]

     }       

    "links": [

        {

            "rel": "self",

            "href: "{id}

        },

        {

            "rel": "delete",

            "href: "{deleteId}"

            "method":"DELETE",

        }        

    ]

}

and 

{

   "id": 123

}

would tell me only "self" is available

whereas

{

   "id": 123,

   "deleteId": 123

}

would tell me both links are.

But I find the self-descriptive link approach 

{

   "id": 123

   "links": [ {"rel": "self", "href": "/123"}, {"rel": "delete", "href": "/123"} ]

}

more intuitive for a user (who might not even need the schema to infer the "delete" relation is available or not". 

If the link is available, then this user might want to lookup the schema link definition to get all other information needed to send proper valid data to the server (without using URI templating at all, from a client standpoint).

I hope I clarified my perspective.

[Geraint Luff]

On 12 February 2013 19:37, Philippe Marsteau <ma...@gmail.com> wrote:

This is not what I meant.

For the following (pseudo)schema:

{

    "properties": {

        [...]

    }

    "links": [

        {

            "rel": "search",

            "method":"POST",

            "schema": {...},

            "encType":"application/json",

            "targetSchema": {...}

        }

    ]

}

I meant receiving the following data:

{

    [...]

    "links": [ {"rel"="search", "href"="/api/search"} ]

}

Now by looking up "search" LDO in schema, I would have all further details about how to interact with that related resource (doing POST, what properties to put and how to encode, etc.).

That's not currently in the specification.  This is partly because it's ill-defined - what if the value of "rel" is "alternate"?  You could easily have several definitions like that in the schema, differentiated only by their target media type.

On the other hand, if the rel is "author", you could also conceivably have several definitions in the data - identical except for the URI (and maybe "title").  What would the rules for matching up links be?

It's definitely interesting.  There is the problem of matching the schema links up to the data links, though - they are both lists containing incomplete information (schema links missing "href", the data links missing everything else).

If there is only one possible link on either side with a given relation, that mapping is easy - it can be done on "rel".  But this is not the case in general.

[Geraint Luff]

OK - there's an idea I've been brewing for a while, which I just described in a new topic.

The basic idea is that instead of simply using "http://json-schema.org/links" as the schema for all links in the data, you should be able to describe the link format itself using hyper-schema.

This would also allow you to add enhancements for certain links.  So with that feature, you would be able to include the links in the data (with more flexibility when it comes to the format), and also explicitly state what extra information the schema supplies about particular links (e.g. links with a particular relation, links where the URI matches a certain pattern, etc.).

Would that be useful for you?

[Philippe Marsteau]

sounds promising. 

In my API currently being designed, I thought of defining a new "Link" structure in my "data representation", so I can add more details about a link and also because in my mind, it is slightly different information than the LDOs that describe the hypermedia schema (e.g. href is a URI template in hyperschema section, whereas a URL in the "data representation" section.

What about adding a unique-ID to LDOs so that you solve the issue of "matching" the LDO to the returned data representation returned link? This would solve the "rel" not unique issue?

[Geraint Luff]

I agree - I've always been a bit uncomfortable with using LDOs in data, due to "href" being a template.  This would mean we don't need that.

 

What about adding a unique-ID to LDOs so that you solve the issue of "matching" the LDO to the returned data representation returned link? This would solve the "rel" not unique issue?

That would work.

However, what happens if you want to match up one-to-many or many-to-one?  For instance, what if you specify multiple rel="alternate" links in the data, and want them all enhanced by the same definition in the schema?

It also feels like that would couple the data and the schema quite tightly.  Imagine if you have a situation like above, with multiple rel="alternate" links (so they all have the same "schemaLinkId" property) - but then you decide that you want to specify some additional info in the schema specifically for the type="application/json" links.  At that point, what should be a schema-only change actually requires a change to the data, because all type="application/json" links now have to reference a different "schemaLinkId".

I think that, ideally, the data format should "make sense" on its own without the schema - but "magic numbers" in the data that reference something in the schema definition are useless noise for any interpreter that isn't using JSON Schema.

So it would work, but it feels kinda inelegant.  I'd rather have a "matchOn" property in the schema link definition that says what fields should be used to match up to any links in the data.  Even more than that, though, I think I'd prefer to not have to match up schema/data links like that at all...

[rods...@gmail.com]

Hello,

this is my first post to this list.

My name is Rodrigo Senra and I am working in a RESTful Hypermedia API that encapsulates a RDF triplestore.

My question is related to rendering links in the schema, and I seek your wisdom on the matter. ;o)

I have a resource that corresponds to a listing of child resources, and it has an associated schema, as follows below:

Data:

{

items:	[ { resource_id: glb @id: http://semantica.domain.com/ title: glb } { resource_id: G1 @id: http://semantica.domain.com/G1/ title: G1 } { resource_id: upper @id: http://semantica.domain.com/upper/ title: upper } ]
next_page:	2
@id:	http://localhost:5100/?per_page=3
page:	1
per_page:	3

}

Schema:

{

links:

[ { href: {@id} method: GET rel: self } ... { href: http://localhost:5100?page={next_page}&per_page={per_page} method: GET rel: next schema: { required: [ page ] type: object properties: { per_page: { default: 10 minimum: 1 type: integer } page: { minimum: 1 type: integer } } } }

The problem is the following:

When rendering the "next" link in the schema, I used URI templates.

Moreover, I included in the schema of the link a properties attribute describing the valid parameters

already present in the URI template.

Is this correct ? Or the definition should me mutually exclusive between: URI templates and properties attribute ?

I am testing this with the JSONBrowser [1] Chrome extension that uses jsonary.

When I expand a form to follow the 'next' link, the form-filled parameters are duplicated with those present in the URI template. 

It is either a bug in JSONBrowser_jsonary or in my understanding of how to materialize json-schemas.

That is why I seek your opinion on this. 

[1] https://chrome.google.com/webstore/detail/json-browser/hngfgkmimoikmpohakflgadcajkfnoba

thanks in advance for your attention

best regards

Rod Senra

http://rodrigo.senra.nom.br

[Geraint]

OK, first: unfortunately "@" is not a valid character for variables in URI Templating.  (to make things even more complicated, "{@}" was the equivalent of "{$}" for version 3 of the draft).

To let people use awkwardly-named variables in link templates, the standard defines some escaping rules for pre-processing.  If you put the variable name in brackets, it should escape it for you:
{
    "href": "{(@id)}",
    "rel": "self"
}

Secondly: the variables in the template come from the data - they are not editable.  However, the "schema" property for links defines extra information to be supplied with the link.  For a GET link, this information is appended as query parameters, for a POST link it will be included in the request body.

So for example, this is how you might describe a "search" link:
{
    "href": "/search",    <--- no variables here!  Variables here come from the data
    "rel": "search",
    "method": "GET",
    "schema": {
        "type": "object",
        "properties": {
            "term": {"type": "string"},
            "resultsPerPage": {"enum": [5, 10, 20], "default": 10}
        },
        "required": ["term"]
    }
}

Use of such link will result in a request URI of something like "/search?term=whatever&resultsPerPage=10"

Does that make sense?

[Geraint]

On Friday, June 28, 2013 4:43:44 PM UTC+1, Geraint wrote:

OK, first: unfortunately "@" is not a valid character for variables in URI Templating.  (to make things even more complicated, "{@}" was the equivalent of "{$}" for version 3 of the draft).

To let people use awkwardly-named variables in link templates, the standard defines some escaping rules for pre-processing.  If you put the variable name in brackets, it should escape it for you:
{
    "href": "{(@id)}",
    "rel": "self"
}

Secondly: the variables in the template come from the data - they are not editable.  However, the "schema" property for links defines extra information to be supplied with the link.  For a GET link, this information is appended as query parameters, for a POST link it will be included in the request body.

So for example, this is how you might describe a "search" link:
{
    "href": "/search",    <--- no variables here!  Variables here come from the data
    "rel": "search",
    "method": "GET",
    "schema": {
        "type": "object",
        "properties": {
            "term": {"type": "string"},
            "resultsPerPage": {"enum": [5, 10, 20], "default": 10}
        },
        "required": ["term"]
    }
}

Use of such link will result in a request URI of something like "/search?term=whatever&resultsPerPage=10"

Just to be clear - in this example, the search term "whatever" and the value 10 are supplied by the user.  They do not come from the data.

If you want to just use variables from the data, you do not need "schema" in your link at all:
{
    "href": "http://localhost:5100?page={next_page}&per_page={per_page}",
    "rel": "next"
}

[Rodrigo Senra]

On Fri, Jun 28, 2013 at 12:43 PM, Geraint <gerai...@gmail.com> wrote:

OK, first: unfortunately "@" is not a valid character for variables in URI Templating.  (to make things even more complicated, "{@}" was the equivalent of "{$}" for version 3 of the draft).

Thanks for pointing that out. I did not manifested it as a question to avoid mixing two points in the same thread. But you answered it nonetheless.

The reason we used @id was an attempt to mix json-schema with json-ld [1].

I'll fix it. 

[1] http://json-ld.org

 

Secondly: the variables in the template come from the data - they are not editable.  However, the "schema" property for links defines extra information to be supplied with the link.  For a GET link, this information is appended as query parameters, for a POST link it will be included in the request body.

...

Does that make sense?

 

Crystal clear. Thank you again from your prompt response.

best regards,

Rod Senra

http://rodrigo.senra.nom.br

 

[pete hug]

So this basically implies that a schema validator must ensure that property names PLUS all specified LDO.rel values for the object are unique, right?

[Geraint]

Sorry, Pete - this is an old topic originally from a year ago, and it's a lot for people to read through.

Would you be able to summarise your question in a new topic, so that it's easier to understand and answer?

Thanks,

Geraint