Module array 

Finding, and later reading, the arrays that live outside the package.

An EnergyML object rarely carries its numbers. It carries a pointer to them, and there are two spellings of that pointer, both in use:

	RESQML 2.0.1 / eml 2.0-2.2	RESQML 2.2 / eml 2.3
in the object	Hdf5Dataset: a DOR to an EpcExternalPartReference, plus PathInHdfFile	ExternalDataArrayPart: URI, PathInExternalFile, MimeType, Count, StartIndex
file name	in the proxy’s .rels, as an externalResource target	in the object, in URI

The newer form is the richer one: it carries the slice as well as the location, which is exactly what ETP’s GetDataSubarrays needs. Both are read here, into one ArrayLocation.

A third pointer is this library’s extension, not the standard’s: a WITSML 2.1 ChannelData whose FileUri names an HDF5 file and whose Data holds the path of a dataset in it (ADR-0013). Located here like the other two, so that everything that walks the arrays of an object - a cut, an import, a rename, a prefetch - carries it along instead of losing it in silence.

The path inside the file is opaque

PathInExternalFile and PathInHdfFile are strings, and nothing else. fesapi writes /resqml22/<uuid>/Points and the convention is convenient, but no part of the schema requires the uuid to be in there, or requires any shape at all. Nothing here parses, splits or validates the path - it is handed to the backend exactly as the object wrote it, and a package that calls its dataset /my/points works. a_path_need_not_contain_a_uuid in the tests pins that down, because it is the kind of assumption that gets added later by someone who has only ever seen fesapi files.

And the format is not necessarily HDF5

Both spellings carry a MIME type, so both can point at something else - a CSV, a Parquet file, whatever a producer and a consumer agree on. eml 2.3 puts it in the part (MimeType); eml 2.0-2.2 put it on the EpcExternalPartReference, where it is a mandatory element whose documentation reads “MIME type for HDF proxy is: application/x-hdf5 (by RESQML convention)” - a convention, therefore, not a rule. The MIME type is what picks the backend; HDF5 is merely the one that ships.

locate is a free function over an object already in memory, not a method on a store. That is the rule the whole crate follows: the store does I/O, the logic sits outside it, and nothing has to be written twice for the synchronous and the asynchronous paths.

Structs

ArrayData

A block of numbers, as read, with the shape it came in.

ArrayLocation

Where one array - or one slice of one - actually lives.

ArrayMetadata

Shape and element type of a dataset, without reading it.

NoProxies

Nothing to resolve with: proxies stay unresolved, the eml 2.3 form still works.

ProxyTarget

What an EpcExternalPartReference stands for.

Resolution

Where an array’s numbers were actually found, and why there.

Enums

ArrayBuffer

A buffer the caller owns, for a backend to decode straight into.

ArrayValues

A block of numbers, in the type the file holds them.

ByteOrder

Which end of a multi-byte number the file writes first.

Traits

ProxyResolver

Turns the uuid of an EpcExternalPartReference into what it stands for.

Functions

file_field

The field of a located part that names its file - what a rename or an import rewrites. uri for the eml 2.3 form; file_uri for a WITSML ChannelData (CHANNEL_DATA). The two proxy forms name no file here (their proxy’s .rels does), and are never asked.

is_array_pointer

Whether a type is one of the two array pointers.

is_channel_data_in_file

Whether a ChannelData’s FileUri and Data are the extension of CHANNEL_DATA - the one definition, which the locator here and the series reader of energyml-domain both ask.

locate

Every array the object points at, both spellings, without a resolver.

locate_with

Every array the object points at, resolving proxies through resolver.

path_field

The field of a located part that holds the path inside the file - path_in_hdf_file for the eml 2.0 form, data for a WITSML ChannelData, path_in_external_file otherwise.