hvdsomp
commented
3 years ago The proposal is to:
- Change the term "attribute" to "parameter"
- Add a paragraph describing the above GS1 use case provided by @philarcher
@mnot, please let us know if not OK.
Closed philarcher closed 3 years ago
hvdsomp
commented
3 years ago The proposal is to:
@mnot, please let us know if not OK.
philarcher
commented
3 years ago Is this the kind of thing you need for an example?:
GET /01/9506000134352?linkType=all HTTP/1.1 Host: id.gs1.org
HTTP/1.1 200 OK Server: nginx Date: Fri, 24 Sep 2021 11:09:07 GMT Content-Type: text/html Link: https://id.gs1.org/01/9506000134352?linkType=all ; rel="alternate" ; type="application/linkset+json" ; profile="https://www.gs1.org/voc/?show=linktypes" Vary: Accept
<!DOCTYPE html>
hvdsomp
commented
3 years ago As I was working on draft material to address @mnot's suggestion to include an example (thanks @philarcher) for the use of the profile parameter for link set media types, it occurred to me that it would also be helpful to have a profile attribute for the linkset link relation type:
profile attribute on a linkset link informs clients about the profile of a link set that is being made discoverableAppropriate wording and examples for both would be included in the I-D.
Thoughts?
philarcher
commented
3 years ago That makes sense to me @hvdsomp, sure.
Would it also make sense in your view to include profile as a member of the linkset itself? IMO it does since we're creating documents that can travel independently of the server from which they come. Sure, you can look through the linkset and see that they fit a given profile, but declaring it at the top of the list in some way might be good. I admit thought, I'm thinking of the JSON object rather than the Link header format - which I don't think could support it.
dret
commented
3 years ago Would it also make sense in your view to include |profile| as a member of the linkset itself? IMO it does since we're creating documents that can travel independently of the server from which they come. Sure, you can look through the linkset and see that they fit a given profile, but declaring it at the top of the list in some way might be good. I admit thought, I'm thinking of the JSON object rather than the Link header format - which I don't think could support it.
if we talk about the RFC 6906 notion of a profile then it easily can be included in the link header format. after all, it's just a regular link, simply one that's using the "profile" link relation type.
hvdsomp
commented
3 years ago philarcher
commented
3 years ago Thanks for doing this @hvdsomp. Please see PR #50 and its comment
hvdsomp
commented
3 years ago Thanks for the edits and PR in #50, @philarcher. If I understand correctly the essence of the change is:
If so, I misinterpreted the set-up. And I am now worried that the resulting example will be confusing, especially when looking at at the change made in the brief link set at the end of the Profiles examples section, where both the “profile” and the “https://gs1.org/voc/whatsInTheBox” links have the URI of the link set as anchor. Given the above, one would expect the latter to have the URI https://id.gs1.org/01/09506000134352?linkType=all as anchor.
In order to make the Profile examples more intuitive/accessible would you be OK to go with the following instead:
After all, the text says “inspired by” the GS1 implementation?
philarcher
commented
3 years ago Hi @hvdsomp
I have obviously caused confusion here, sorry. I'll keep this as brief as I can but I do need to set out the stall a little.
As you surmise, the GTIN is 9506000134352.
You know it's a GTIN because the preceding path element is 01 (there are lots of other 'application identifiers', for example, '10' is a batch number, 17 an expiry date and so on).
The GS1 Digital Link standard sets out how to put all this into a URI. Which is why, I must push back strongly on a suggested URI of https://gs1.org/product/?gtin=09506000134352.
So what's id.gs1.org? That's a GS1 resolver. How do you know? Because there's a Resolver Description File at /.well-known/gs1resolver. I'm speaking at a session at the IEEE this week on the topic of identifiers and resolvers should you be interested in seeing my pre-recorded presentation.
What does a GS1 resolver do?
It has multiple links for a given item. Each link has a defined link relation type (we shorten this to just 'link type' for convenience). One of them is the default link. If you go to just https://id.gs1.org/01/9506000134352 you'll be redirected to that default. Actually, we can go a bit further, there might be multiple 'default links' that are differentiated by attributes that can be discerned from an HTTP request - hence the concept of 'defaultLinkMulti'.
You can ask a conformant resolver for a specific type of link. In the example we use everywhere, you can ask for a recipe that uses the product, or info about its sustainability. Do this by appending the GS1 Digital Link URI with a value for the linkType parameter. For example: https://id.gs1.org/01/9506000134352?linkType=gs1:productSustainabilityInfo Now you're redirected to a different URL than if you omitted the linkType parameter.
But suppose you don't want to be redirected, you just want the linkset. How do you do that?
Two methods.
Set the Accept header to application/linkset+json (we have yet to implement application/linkset) or set the linkType parameter to all. The latter option is most likely to return an HTML page containing the links but you can use conneg to get it in different formats.
Therefore
The anchor for a linkset is https://id.gs1.org/01/9506000134352
The URL for the linkset (ignoring conneg) is https://id.gs1.org/01/9506000134352?linkType=all
I understand that this is confusing and what you want is a nice simple example. Therefore we can use 'inspired by GS1' to get around some of this complexity, especially as our implementation is not yet perfect (it's on the backlog but ...) But please, do not use https://gs1.org/product/?gtin=09506000134352 anywhere. If needs be, just use https://www.gs1.org/voc/?show=linktypes as the profile URI without using our resolver as the example server.
HTH
hvdsomp
commented
3 years ago Manually addressed the URL issues from @philarcher's PR #50 in https://github.com/ietf-wg-httpapi/linkset/commit/6c218d387c5fa36bec72e544dece557f0105313c. With that, all changes proposed in PR #50 have been addressed.
philarcher
commented
3 years ago Propose this issue be closed as it's been dealt with (I'm happy with the edits in the examples - thank you @hvdsomp)
hvdsomp
commented
3 years ago Closing. Addressed in https://www.ietf.org/archive/id/draft-ietf-httpapi-linkset-04.html
Mark says (https://mailarchive.ietf.org/arch/msg/httpapi/gv9uqyD8Fv96P-_ip9LWIiCqALM/)
I admit I had not grokked this section before today but actually, now I have, I can immediately see its value and can even provide an example that we can include in our implementation in the relatively near future.
A Linkset from GS1 is going to include link relation types from the set we define. May the court have mercy but we abbreviate 'link relation type' to link type and the list of all currently GS1-ratified link types is visible at https://www.gs1.org/voc/?show=linktypes. We could add a profile attribute, sorry, profile parameter, and include that URL.
Since that list of link types is under change control of a recognized SDO (GS1), including this as an example would, I hope, be appropriate here?