gs1 / gs1-syntax-dictionary Goto Github PK

Hello,

The documentation gives the following resolution for dlpkey 10 with GTIN:
"dlpkey=22,10,21" - As above, with ordered, optional qualifier AIs
"https://../01/../22/../10/../21/.." - valid
"https://../01/../22/../21/.." - valid (good order)
"https://../01/../10/.." - valid (good order)
"https://../01/../10/../22/.." - invalid (bad order)

With SSCC:
"https://../00/..?02=..&37=..&10=.." - valid

Is this a unique case? Or is it a special rule?
Are there any other cases where a dlpkey would be translated this way?
"https://../PrimaryKey/..?KeyQualifier=.."

Per Figure 4.13.2-1 of the GenSpecs, this should be req=00 req=37.

The pattern "NN+NN" doesn't exist anywhere in the AI data.

The presence of '|' in dlpkey is redundant, as the same restrictions can be discovered by looking at the "ex=" entries. Having the same restrictions in two places leads to the possibility of bugs (one of which is raised in a separate issue).

The use of iso3166list is a problem for simple validators that are concerned only with structural validation (i.e., type and length). The way AIs 423 and 425 are defined, a structural validator would allow "1234" to pass.

I suggest these be rewritten using the optional terminology as follows:

423         ?  N3,iso3166 [N3,iso3166] [N3,iso3166] [N3,iso3166] [N3,iso3166] req=01,02 ex=426                     # COUNTRY - INITIAL PROCESS
424         ?  N3,iso3166                    req=01,02 ex=426                     # COUNTRY - PROCESS
425         ?  N3,iso3166 [N3,iso3166] [N3,iso3166] [N3,iso3166] [N3,iso3166] req=01,02 ex=426                     # COUNTRY - DISASSEMBLY

An alternative would be to borrow the repetition syntax from regex:

423         ?  N3,iso3166{1,5}               req=01,02 ex=426                     # COUNTRY - INITIAL PROCESS
424         ?  N3,iso3166                    req=01,02 ex=426                     # COUNTRY - PROCESS
425         ?  N3,iso3166{1,5}               req=01,02 ex=426                     # COUNTRY - DISASSEMBLY

The '?' character indicates an "AI that is permitted as a GS1 Digital Link data attribute". The naive interpretation of this flag is that the AI is permitted in the query string, but every AI with the dlpkey attribute set also has this flag set, so this could lead to an incorrect implementation where a dlpkey AI ends up in the wrong place, e.g., https://id.gs1.org/00/095212340000000006?00=095212340000000006.

Secondary keys, such as AI 21, don't have this flag set.

In my opinion, this flag should be removed for dlpkey AIs.

Figure 4.13.1-1 of the GS1 General Specifications defines the current set of invalid pairings of GS1 Application Identifiers.

Within that table in the current version of the GS1 Gen Specs, I don't see any evidence for invalid pairings for any GS1 Application Identifiers in the range 3100 - 3695 in the first or third columns of that table, so unless there is a ratified General Specification Change Notice (GSCN) at https://www.gs1.org/standards/genspecs/gscn_archive that updates Figure 4.13.1-1 we should take great care not to suggest invalid pairings within the Barcode Syntax Resource dictionary that are not explicitly stated in the GS1 General Specifications nor within a ratified GSCN that will be implemented in the next publication of the GS1 Gen Specs.

This issue concerns lines 129-181 of https://github.com/gs1/gs1-syntax-dictionary/blob/2023-07-04/gs1-syntax-dictionary.txt where we currently see entries such as 3100-3105 * N6 req=01,02 ex=310n.

Even the note (3) for Gen Specs Fig 3.2-1 for GS1 Application Identifiers in this range does not forbid the use of more than one AI within each range. The note is only concerned with pointing out that the fourth digit indicates the number of decimal places.

While I accept that it would be advisable not to use AIs within the same range together, e.g. don't use (3103) and (3102) together, such a rule is currently not officially stated in the Gen Specs table of invalid pairings and it is potentially problematic to formulate this as 3100-3105 * N6 req=01,02 ex=310n because if we pick one AI within that range, e.g. (3103), then the notation 310n is usually considered to apply to all AIs in that range, e.g. (3100)-(3105), without excluding any individual AI in that range that we happen to select.

Would ex=310n then be considered to apply also to the single AI within that range that we select? i.e. it's mutually exclusive with itself. This could cause confusion and we certainly don't want any implementations of the Barcode Syntax Resource to reject a single occurrence of AIs within each range within 3100-3695, where they are used appropriately and in accordance with the GS1 General Specifications, simply because of a misinterpretation of statements such as ex=310n

A comparison with, GS1 Syntax Engine GUI demo and my personal development to explain my problem.

1) With GS1 Syntax Engine GUI demo

Input data :

(01)00883873867792(22)AvBn220707(10)220707(21)PC22412085

Detected syntax:

Bracketed AI element string

Barcode message (^ = FNC1):

^010088387386779222AvBn220707^10220707^21PC22412085

GS1 AI element string:

(01)00883873867792(22)AvBn220707(10)220707(21)PC22412085

HRI test:

GTIN (01) 00883873867792
CPV (22) AvBn220707
BATCH/LOT (10) 220707
SERIAL (21) PC22412085

2) With my development:

Input data :

(01)00883873867792(22)AvBn220707(10)220707(21)PC22412085

GS1 AI element string:

(01)00883873867792(10)220707(22)AvBn220707(21)PC22412085

HRI test:

GTIN (01) 00883873867792
BATCH/LOT (10) 220707(22)AvBn220707
SERIAL (21) PC22412085

We can see that AI 22 is not recognized because the pattern [!%-?A-Z_a-z\x22] considers parentheses to be part of AI 10.
How do you handle this case?
Thanks for your help.

After further discussion with @mgh128 and in light of his comment on the original issue, I think we should put back the "GS1 Digital Link attribute" flag on all primary keys.

Section 4.10 of the GS1 Digital Link Standard: URI Syntax includes the following (emphasis mine):

Note that ‘data attributes’ MAY include AIs that may also be used as primary keys, as defined in sections 4.3, 4.4. In any GS1 Digital Link URI there SHALL be exactly one primary key, followed by any key qualifiers relevant to that primary key as path elements. However, the GS1 General Specifications allow combinations of primary keys in a single data carrier. For example, it is possible to encode both a GTIN and a GIAI in a single element string within a data carrier (see the example in section 5.11). Where it is necessary to encode more than one primary key in a single GS1 Digital Link URI, one SHALL be used in the path and the remaining key(s) encoded in the query string as data attributes.

This too is not entirely correct; the first sentence should read, "Note that ‘data attributes’ MAY include AIs that may also be used as primary or secondary keys...".

Reviewing the syntax dictionary yet again, I find that the secondary keys for AI 01 have the flag set for AI 10 but not for 21, 22, and 235. We should put the flag back on all primary and secondary keys, and do a thorough review to ensure that the flag is correctly set or unset for all AIs.

Hello,
Concerning dlpkey, the AIs concerned are still 22, 10 21 or 235?
I don't quite understand how the GS1 Digital Link primary key works.
Does it condition the validity of a GS1 Digital Link URI?
Could you explain this further?
Best regards

All references to GS1 Digital Link should use the full name; "Digital Link" is trademarked by another company. Abbreviations (e.g., dlpkey) are fine as they are.

Similarly to #9, the mmoptss option causes problems for structural validators; the value "123" would be perfectly legitimate. I suggest instead replacing "[N..4]mmoptss" with "[N2]mm [N2]ss" to better reflect the requirement.

Numerous AIs are numeric with a decimal point implied by the last digit of the AI.

• 31nn
• 32nn
• 33nn
• 34nn
• 35nn
• 36nn
• 39nn

Automatic encoding and decoding would be aided by adding a "decimal" linter type, i.e.,:

...
3100-3105  *?  N6,decimal                    req=01,02 ex=310n                    # NET WEIGHT (kg)
3110-3115  *?  N6,decimal                    req=01,02 ex=311n                    # LENGTH (m)
...
3900-3909   ?  N..15,decimal                 req=255,8020 ex=390n,391n,394n,8111  # AMOUNT
3910-3919   ?  N3,iso4217 N..15,decimal      req=8020 ex=391n                     # AMOUNT
...

AIs 254 and 7040 are mutually exclusive. However, this restriction appears only in dlpkey, not in ex.