path pattern : regular expression vs. examples

[Airy59]

Currently, ifcx.tsp stipulates:

@pattern("</[A-Za-z0-9_/.:]+>")
scalar path extends string;

model IfcxNode {
    path: path;
    children?: Record<string | null>;
    inherits?: Record<string | null>;
    attributes?: Record<unknown>;
}

The pattern decorator for path accepts a regular expression that does not include hyphens -, and more generally would exclude paths found in example, such as "path": "25503984-6605-43a1-8597-eae657ff5bea" (in hello-wall.ifcx) where the start '</' and end '>' are missing.

Also, even if the pattern were corrected to allow UUIDs, it might still exclude URIs or IRIs, which can be made unique using adequate strategies when needed. What are the reason(s) to deter from using URIs?

[aothms]

it might still exclude URIs or IRIs, which can be made unique using adequate strategies when needed. What are the reason(s) to deter from using URIs?

I think this was a rather conscious decision hint at dereferencability or webrequests to unknown hosts for security and ease of processing. Even the import uri took quite some discussion.

The path regex indeeds needs to be adapted. Feel free to send in a pull request :) The <...> was USD syntax that we incorporated in earlier examples but should now be eliminated. / and - should indeed be allowed.

Not sure how I feel about requiring a leading slash / as is now in the regex, makes it clearer it's a path as opposed to a single uuid.

[Airy59]

data interoperability

Wholesale exclusion of URIs from paths is a serious limitation, and contradicts the declared aim of opening IFC to broader usages. Also, it hampers referencing of other models by IFC. Latter goal was not stated (if memory serves) but is no less important, IMHO:

An example is, IFC5 currently deriving quantities and units from QUDT without explicit reference, thus creating another autonomous island on a subject that is not owned by BIM. Why nearly every other model (not only IFC5, I could quote other fresh examples) needs to reintroduce acceleration and meter per second squared is not clear to me, but what I observe is that people still are making mistakes (Mars Climate Orbiter, 1998, got avatars). I'll leave that for another issue though.

ease of processing

In contexts where information about an entity is scattered across several files or JSON snippets, I do not quite see what additional difficulties would be entailed by using URIs as unique identifiers, rather than UUIDs, except of course that ensuring unicity of URIs requires a strategy. But I'd leave that concern for the implementer to manage, rather than deciding in his stead.

security

Excluding URIs from paths is, IMHO, neither a necessary nor a sufficient condition for secure data exchange.
In the current state of IFC5 alpha, you are already using URIs to point to bSDD entries, albeit not via the path key:

        "bsi::ifc::presentation::opacity": 1,
        "bsi::ifc::material": {
          "code": "CONCRETE",
          "uri": "https://identifier.buildingsmart.org/uri/fish/midas-materials/26/class/CONCRETE"

Anybody could tamper with the value behind "uri". Besides, that property should be called "bsdd_definition" if that's the exact intent.