gs1 / gs1-syntax-dictionary Goto Github PK

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.

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.

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

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).

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

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=.."