Localized String Syntax for 0.FDO/Name and Description

[Pfeil]

For name and description, I was trying to figure out how to model it properly.

I thought that for both, the syntax could be the same: A serialization of some string and a ISO639 language tag. In our case, we'd expect in JSON, e.g.

{
"prefix/StringSyntax": "Any kind of string",
"prefix/LangugeTagIso639": "en"
}

I thought I'd simply define this and reuse it for 0.FDO/Name and 0.FDO/Description.

Now, you see that this "LocalizedStringSyntax" is pretty generic (on purpose). It contains no strict semantics and should not be used as an attribute directly. Therefore, it should not be an AttributeDef, but a SyntaxDef.

At the same time, I need to use 0.FDO/ValidationMechanism and 0.FDO/DataType to compose two syntaxes. Those are only in AttributeDef, not in SyntaxDef, though. The specification does not forbid me to do it, but as a developer, I wonder if I SHOULD do it? I am unsure because:

• Will implementations use/recognize this?
• Should the specification be more attribute-driven than "type-driven"? At least for the implementation I will consider re-designing the foundational model in the long run to be more flexible. If this is successful, it might be more developer friendly to go this way.

---

Attachments:

Record draft of 0.FDO/LocalizedStringSyntax

{
  "0.FDO/Type": [
    "FDO_Syntax_Definition"
  ],
  "0.FDO/Profile": [
    "0.FDO/SyntaxDef"
  ],
  "0.FDO/Data": [
    "Not_Applicable"
  ],
  "0.FDO/Name": [
    {
      "value": "Localized string",
      "lang": "en"
    }
  ],
  "0.FDO/Description": [
    {
      "value": "Specifies the way to express a string value that is localized to a specific language.",
      "lang": "en"
    }
  ],
  "0.FDO/ValidationMechanism": [
    "InlineCombination"
  ],
  "0.FDO/DataType": [
    "0.FDO/StringSyntax",
    "0.FDO/LanguageTagIso639"
  ]
}

---

Alternatives I considered:

• Some specialized syntax, not composing/combining FDOs
  • Not really reusable (hides semantics from the common semantic layer of FDOs)
  • adds a second "shadow structure" (more parsing required)
  • Doesn't feel native to our approach, I wanted to try what exists already
• Using 0.FDO/Name as a main label (not localized), and expect users to somehow inherit the name semantics and create a new type
  • How to expect consistent reuse if it is not in core?
  • We do not really have the semantics transport defined, maybe with 0.FDO/Extends? Currently, Extends is quite special, e.g. only transports 0.FDO/Attribute and other profile-specific information
  • If we would have it defined, can we replace it with 0.FDO/Name? I think we did not specify yet.

I wonder if I miss something in the specification.

[jboehm1911]

• If I understand correctly, you want to model a string as a combination of an instance (Any kind of string) and a language (en).

My thoughts about this:

• Currently, there is no way to compose two syntax definitions (according to the FDO specification). Rather, you would need to wrap each syntax definition into an attribute definition (that is, give it a name, a description and a cardinality), and then those can be composed using the inlineCombination mechanism.

• I had the same issue when modelling some simple example JSON schemas: A full_name is a combination of a first name and a last name. But maybe I do neither want to model first name nor last name as stand-alone attributes. Rather, it would be enough to build an inline-combination of two strings and assign each of them a name, description and cardinality (i.e., build some kind of inline-attributes). Here is how this could look like: https://github.com/fairdo-org/handle_fdo_specification/blob/main/json-schema/%5BH5-5%5D_Inline_Combination/SyntaxDef_Full_Name.json (lines 21-31, and remove the reference to the attribute definition in line 24).

• I think it would make sense to allow inline combinations of syntax definitions in the FDO specification. We use inline combinations if the parts of the inline-combinations should not be attributes on their own.

[Pfeil]

Good points, thank you.

I think it would make sense to allow inline combinations of syntax definitions in the FDO specification. We use inline combinations if the parts of the inline-combinations should not be attributes on their own.

Exactly my thoughts. Another good reason: We cannot prevent that people model things like this. And I think where it really makes sense, the specification should act gracefully and say "Ok, we see this would semantically make sense, so we just allow it". Similar to how a wrong closed html tag nowadays is not an issue anymore for browsers.

[maximiliani]

Options discussed on 2026-08-25:

1. Enable 0.FDO/ValidationMechanism and 0.FDO/DataType attribute on Syntax Definitions
2. Introduce a new attribute 0.FDO/isCombinationOf (using Profile Reference to only allow references to SyntaxDef) for Syntax Definitions
3. Remove Inline Combinations from attributes (attributes could use profiles and inline-FDOs instead) and move it entirely to Syntax Definitions
4. Redesign 0.FDO/ValidationMechanism