There are duplicate keys in UNECE-BSPContextCCL.json:

'noteType' :

    "noteType": {
      "title": "Note. Details",
      "description": "A textual or coded description, such as a remark or additional information.",
      "uncefact:type": "AggregateBIE",
      "uncefact:cefactUNId": "UN01002519",
      "uncefact:cefactBusinessProcess": "In All Contexts",
      "type": "object",
      "properties": { ... },
      "$ref": "UNECE-BasicComponents.json#/$defs/extensibleType",
      "unevaluatedProperties": false
    }

and

    "noteType": {
      "title": "Specified_ Note. Details",
      "description": "A specified textual or coded description, such as a remark or additional information.",
      "uncefact:type": "AggregateBIE",
      "uncefact:cefactUNId": "UN01015368",
      "uncefact:cefactBusinessProcess": "In All Contexts",
      "type": "object",
      "properties": { ... },
      "$ref": "UNECE-BasicComponents.json#/$defs/extensibleType",
      "unevaluatedProperties": false
    }

'subordinateLocationType':

    "subordinateLocationType": {
      "title": "Subordinate Subordinate_ Location. Details",
      "description": "A physical location or place which is a subordinate location of a subordinate location.",
      "uncefact:type": "AggregateBIE",
      "uncefact:cefactUNId": "UN01004087",
      "uncefact:cefactBusinessProcess": "In All Contexts",
      "type": "object",
      "properties": { ... },
      "$ref": "UNECE-BasicComponents.json#/$defs/extensibleType",
      "unevaluatedProperties": false
    }

and

    "subordinateLocationType": {
      "title": "Subordinate_ Location. Details",
      "description": "A physical location or place which is a subordinate location of a location.",
      "uncefact:type": "AggregateBIE",
      "uncefact:cefactUNId": "UN01004092",
      "uncefact:cefactBusinessProcess": "In All Contexts",
      "type": "object",
       "properties": { ... },
      "$ref": "UNECE-BasicComponents.json#/$defs/extensibleType",
      "unevaluatedProperties": false
    }

Hi there
I'm creating this issue as a question, I don't have a lot of context as I found out about this from reading the PDF at at https://unece.org/sites/default/files/2022-09/API-TECH-SPEC_JSON_Schema_NDR_version1p0.pdf

In the PDF, the unqualified dateTimeType seems to suggest that it will be a string with the jsonschema date-time format whereas the examples in this repo seem to suggest that it will be an object with two string fields (content and an optional format).

I'm wondering if this is a change in direction or if one of the github/pdf are just out-of-date.

The regex for decimal strings in the schema is proposed as "^([+-]?(0?|[1-9][0-9]*)(\\.?\\d+))$"

This isn't compatible with json's numeric representations and isn't compatible with most languages' float/doule toString implementations which will use E notation when the exponent is large enough.

This is just a question on whether there'd be interest in expanding this regex to allow exponent notation. The reason is that it's a lot easier for users of this jsonschema to convert their json or domain data to the appropriate types.

With exponents supported it's a simple toString, without them a user needs to first use a library to get a full positional string - this creates some friction whenever converting number to strings that match the jsonschema.

(not sure if this spec is finalized or still in draft)

Hi,

Can the unit conversion details be added to the JSON Schema output, please?

We had this on the original Excel export, so it should be possible to include it on the JSON Schema too.

We need this to properly link from QUDT (big win!). Please ref w3c-ccg/traceability-vocab#536 (comment) on more details on these requirements.

Link from https://unece.org/trade/trade-facilitation-and-e-businessuncefact/json-schema-naming-and-design-rules for the pdf points to https://unece.org/sites/default/files/2022-09/API-TECH-SPEC_JSON_Schema_NDR_version1p0.pdf but the document there has become "BUSINESS REQUIREMENTS SPECIFICATION (BRS) CROSS INDUSTRY DESPATCH AND RECEIVE PROCES"

The link used to work as of approximately a month ago.

During code lists parsing I've found that at least two code lists have duplicate constants in them:

1. https://github.com/uncefact/spec-JSONschema/blob/main/JSONschema2020-12/meta-library/BuyShipPay/D22A/codelists/UNECE_UNTDID4405.json#L14-L20
2. https://github.com/uncefact/spec-JSONschema/blob/main/JSONschema2020-12/meta-library/BuyShipPay/D22A/codelists/UNECE_UNTDID8023.json#L102-L132

@kshychko can you add an example of this, pls?

Just a question,

In this Cross Industry Invoice, it includes the fields

"applicableHeaderTradeSettlement": {
                "specifiedTradeSettlementPaymentMeans": {
                    "payerPartyDebtorFinancialAccount": {
                        "typeCode": false
                    }
                }
}

And in the JSONLD Spec, also under uncefact, I believe the equivalent would be:
https://vocabulary.uncefact.org/applicableTradeSettlement
https://vocabulary.uncefact.org/specifiedPaymentMeans
https://vocabulary.uncefact.org/payerPartyFinancialAccount
https://vocabulary.uncefact.org/debtorFinancialAccountTypeCode

Which follow the same nested pattern.

Is there a reason for the subtle differences between the naming? Are we able to translate easily between names or is any standardisation happening between the JSON Schemas and the JSON LD Project.

Cheers,

The uncefact spec mandates using a jsonschema date for the "YYMMDD" format. It's not listed as one of the untdid2379JsonType types that requires an additional context.

This is consistent with the ccts->edifact mappings recommended here - https://unece.org/DAM/cefact/codesfortrade/CCTS/CCTS-DTCatalogueVersion3p1.pdf
For YYMMDD it declares "Map to semantically equivalent ISO representa-
tion without century truncation"

What I'd like to know is what the recommended approach is for choosing the century for a date that only specifies the decade. Different libraries to different things and it'd be good to make sure we're confirming to the unece instead of some arbitrary library.

EG: Libraries always choose the century based on the current date. However they don't all have the same rollover points depending on the current date. EG: Today some libraries might map centuries from 00-70 to the 20th century and 71-99 to the 19th, other libraries might choose 00-69.

What is the recommendation for how the CC should be created for YYMMDD dates?