Schema element "`c:path_split`"

Explains which part of a path is a sub-collection name, and what is a local Unit name.

Definitions

<element name="path_split" type="b:Expression" />

Description

The external name of a Unit might by picts:Holiday/2023. The b:namespace takes care of physical addressing the right servers for picts:. The namespace is managed by the owner of the server.

The c:collection determines how Holiday/2023 is interpreted. Either it contains a Unit named Holiday/2023, or it has a sub-collection Holiday which contains a Unit named 2023. This path_split expression determines how to interpret that relative path. See examples.

The path_split expression should either return

one single local unit-id,
a single new relative b:UnitRef,
a (blank separated) triplet of local unit-id, detected separator, and relative path within a sub-collection, or
a (blank separated) triplet of b:UnitRef, detected separator, and relative path within a sub-collection, or

In the first case, when the unit-id is not the same as the path, then path_split will be re-evaluated with the new value. This will also happen to the unit-id returned in the third case.

When a UnitRef is returned, it will be re-evaluated according to the usual look-up process. This will probably lead to a different collection.

Examples

The default path_split rule

The default expression splits on a '/'.

path =~ "^([^/]+)(/)(.*)" -> $1 ~ ' ' ~ $2 ~ ' ' ~ $3

It is RECOMMENDED to stick to the default separator rule, which implements the commonly used "/" separator, like in HTTP URLs. Also, it is RECOMMENDED to stick to one separator for the whole namespace. However, there are reasons to diverge (see other examples)

Multiple strategies within on Namespace for path_split

It is useful to keep life simple, but reality may catch-up. For instance: originally, the documentation of product "xyz" was in a unit inside the same Namespace (Collection) named "xyz.pdf". Later was decided to create a separate namespace for the documentation. All pdfs were moved to a new subspace "Docs". However, the path of the old location is still known on other places.

This can be solved like this:

json
xml

<b:definitions>
  <b:let b:name="moved_pdfs"
      b:be="path =~ '^([^/]+\.pdf)$' -> 'Docs/' ~ $1" />

  <b:let b:name="default_path_split"
      b:be="path =~ '^([^/]+)(/)(.*)' -> $1 ~' '~ $2 ~' '~ $3" />

</b:definitions>
<c:collection>
  <c:path_split>moved_pdfs // default_path_split</c:path_split>
</c:collection>

{ "b_definitions" : {
    "b_let" : [ {
      "b_name" : "moved_pdfs",
      "b_be" : "path =~ '^([^/]+\.pdf)$' -> 'Docs/' ~ $1"
    }, {
      "b_name" : "default_path_split",
      "b_be" : "path =~ '^([^/]+)(/)(.*)' -> $1 ~' '~ $2 ~' '~ $3"
    } ]
  },
  "c_collection" : {
    "c_path_split" : "moved_pdfs // default_path_split"
  }
}

When a pdf name is encountered, it is first rewriten into Docs/*.pdf, which is different than the original so the splitting is started again. Now the default_path_split rule is triggered, which returns three components. The first Docs will be split again, now not leading to anything new.

Useful playing with different path seperators

Let us assume that our collection of company internal network information is accessible via endpoint https://facts.example.com/network. When assign prefix net: to that namespace for our convenience.

The collection tree could be designed like this:

net:                path-split on '/'
 ├─> ipv4           path-split on '.'
 │     ├─> 10           Subnet free to use
 │     └─> 192.168.1    Subnet managed by someone
 │           ├─> 11     Unit describing one interface
 │           └─> 12
 └─> ipv6           path-split on ':'
       └─> 2001:0db8:85a3:0000:0000
             └─> 8a2e   Subnet managed by someone
                  └─> 0370:7334   Unit for service

The absolute b:UnitRef of host 11 is net:ipv4/192.168.1.11. Per sub-collection, you may have different access-rights: different maintainers. Physical server maintains can, using b:namespace, map the private network sets to local storage, where the rest is globally visible.

mark@overmeer.net Web-pages generated on 2023-12-19