tballison commented on PR #3451:
URL: https://github.com/apache/tika/pull/3451#issuecomment-6473448128
The main missing piece is typed values. @krickert @dpol1 wdyt of this,
potentially?
```
Proposal: typed values without locking in types
v2alpha1 sends every metadata value as a string, with type and cardinality
hints from Tika's metadata registry. To spare
clients from parsing, the server can also send typed copies:
message Values {
repeated string values = 1; // always present
ValueType type = 2;
Cardinality cardinality = 3;
// set only when the hint is typed and every value parses
repeated int64 integers = 4;
repeated double reals = 5;
repeated bool booleans = 6;
repeated google.protobuf.Timestamp instants = 7; // zoned dates only
}
- Strings stay the source of truth. Typed copies are derived from them. If
a key's type changes, its typed copy moves to
another field or disappears, and the strings don't change. Type changes
are gated in tika-metadata-schema
(type-changes.json).
- Nothing is guessed. If any value fails to parse, there's no typed copy.
Dates with no zone, and date-only values, stay
strings, because a Timestamp can't represent "floating" without
inventing UTC.
- No top-level Dublin Core fields for now. With typed copies,
dcterms:created and similar keys already arrive typed in
metadata. Promoting document properties is how the format taxonomy
creeps back in.
- Structural tk: values may become fields. These describe the parse
itself, not the document, and Tika owns them.
Candidates: per-document exceptions, the content handler type, and a
"content truncated" flag. They'd stay in metadata
too, so it remains a full /rmeta mirror.
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
