Schema element "b: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" default="'[/]'" />
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 b: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 (sub-)collection "Docs". However, the path of the
old location is still known on other places.
This can be solved like this:
<definitions>
<let name="moved_pdfs"
be="path =~ '^([^/]+\.pdf)$' -> 'Docs/' ~ $1" />
<let name="default_path_split"
be="path =~ '^([^/]+)(/)(.*)' -> $1 ~' '~ $2 ~' '~ $3" />
</definitions>
<collection>
<path_split>moved_pdfs // default_path_split</path_split>
</collection>
{ "definitions" : {
"let" : [ {
"name" : "moved_pdfs",
"be" : "path =~ '^([^/]+\.pdf)$' -> 'Docs/' ~ $1"
}, {
"name" : "default_path_split",
"be" : "path =~ '^([^/]+)(/)(.*)' -> $1 ~' '~ $2 ~' '~ $3"
} ]
},
"rules" : {
"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
| 
