A first look at Resolver CE's new data entry format #88
Replies: 2 comments 1 reply
-
Much better 👌🏽 Are these changes backwards compatible? - in other words, will existing integrations continue to work? |
Beta Was this translation helpful? Give feedback.
-
Delighted to see these changes, @nicklansley. Thank you. This feels good! Just two nit picks:
should be "gs1:epil", i.e. the namespace is important. I admit that there's no formal way here to define the namespace, so one could argue it's moot, and, yes, we probably should work to introduce to the Linkset RFC but for now we should just make sure we use the namespace consistently. And this looks questionable?
i.e. keeping the "und" value as well as "marketing"? Oh, one more, sorry...
That's deprecated as of GS1-Conformant resolver 1.0.0 in favour of |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Nick Lansley writes:
Hello!
One big cause of frustration for Resolver CE users was the large, unwieldy, and confusing data entry format for v1/v2 versions of Resolver!
Although it started simply enough, the addition of all those 'default' flags turned an 'OK' data entry format into a confusing nightmare. And yes, you can blame me for that design - It worked but you know you've left the track of simplicity when even developers are getting confused!
No more! Let's look the new data entry format supported by Resolver CE v3.0 API:
Let's compare it to the original input with the same data:
So, what just happened?
identificationKeyType
andidentificationKey
have disappeared. Instead, a newanchor
property has appeared that holds the URI stem of the GS1 Digital Link identifier.qualifierPath
has been replaced by aqualifiers
array that contains one or more relevant qualifiers for this entry. The qualifiers can be in any order, although Resolver CE will respond to them according to GS1 standards - for example, a serial number is subject to a particular lot number if both are included in the array. Template variables can be used as qualifier values as before.defaultLinkType
,defaultLanguage
,defaultContext
, anddefaultMimeType
have completely disappeared. Instead, there is a new propertydefaultLinkType
specified towards the top of the entry that signifies which link type is the default. The other three defaults are inferred from your data - no need to explicitly state them.ianaLanguage
has becomehreflang
, which more effectively reflects its purpose: 'the language of the link reference'. It has been expanded to optionally include locale/territory, allowing Resolver to read the 'accept-language' header from a web client and act on it when choosing an appropriate link. Examples include 'en', 'en-GB', 'en-US', 'fr-FR'. A singlehreflang
property is an array of one or more language-and-optional-locale entries suitable for the link. If the language is not applicable, we've replaced 'xx' with 'und' (for undefined) as this is a standards-compliant value.context
has become an optional array of strings. Some enterprising developers press-ganged context to be used for 'locale'. Fortunately,hreflang
takes over this important consideration, leaving context to return to being used to provide filtered contexts for choosing the link, chosen by the optional query string element 'context=' added to the end of the GS1 Digital Link URL by a smart web client. If you only used context 'xx' before then there is no longer supply context at all. If some entries apply to both particular contexts and 'no context' then you can use values like"context": ["marketing", "und"]
where 'und' is 'undefined' just like 'hreflang' uses it.active
has disappeared. This property was part of an original design to enable links to be available or hidden. This property was never used as end-users never needed this functionality. Why put the link in Resolver CE if you don't want it public?!fwqs
has also disappeared. 'Forward Query Strings' was included in v1.0 of Resolver CE because one of our earliest tester's websites kept crashing if it received query strings it was not expecting! This effect has never been seen since and is never used. It's time we let it go.You may already be familiar with 'linkset' output from Resolver CE if you append 'linktype=all' to the GS1 Digital Link URL request, and add request header 'accept-language: application/json' or 'accept-language: application/linkset+json' to the request. If so, you may look at the data entry input format above and conclude that it is similar? No coincidence! The data entry is a simplified form of the linkset output. Let's look at the same data in the linkset output format:
Well... if you want to, you can upload fully formed linkset data as data entry!
There is some greater complexity involved in authoring linksets (and Resolver CE will thoroughly check you have it perfect), thus the simplified version is easier to understand. What is important is that the linkset is the internal data structure stored in the document database. If you upload the simplified version, then it will be authored for you.
That's a first look at the new data entry format for GS1 Digital Link Resolver CE v3.0 - comments welcome!
If you a CSV data uploader, all good - the UI will still be there to convert your CSV documents and upload them for you.
Nick Lansley
Beta Was this translation helpful? Give feedback.
All reactions