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.

regex suggestion

URIs follow and ABNF grammar that is not easily restricted to a regular expression. There is no "standard" regex equivalent for it. So in the context of the present discussion, fixing the regex is too early as long as the background question (allowing URIs or not) remains open.

[tomvandig]

@Airy59 Could you explain in more detail why the path field should allow URIs? To be clear: the path field only identifies entities, not data, and is meant to be composable.

[Airy59]

Precisely because using URIs is a valid means for identifying entities. Then, if composing UUIDs is a necessary feature, you could still use the path part of the URI for that purpose.

[tomvandig]

@Airy59 I understand that it may be a valid means of identifying entities, but there are many valid ways to identify entities. You mentioned earlier that this poses a serious limitation, I would like to understand why.

Fundamentally, the composible nature of the data makes it strange to address an entity with a URI, as there is no entity owner or single unique resource location for an entity, but rather only descriptions of data that compose together into a completely formed entity.

On top of this, the data in the ifcx file can be identified through a URI already, so in some sense you could say that the ifcx file URI + the entity UUID/path is itself a URI for the entity (but in relation to that specific file, as the entity itself is not a single thing).

Maybe I am missing the point, so could you provide a concrete example?